企业应用的Web程序的安全性

提起安全性这个话题，大家恐怕依稀还记得Sony的PSP账户信息泄露的事故造成的重大损失。但是又隐隐觉得这事儿离我很远，无需过多考虑。也有的人会想，我们做的是企业内部系统所以不必太在意。但是，Web程序的安全性已经悄然来到你我身边，我们在使用的系统太多的并没有充分考虑安全性。这样的系统只是尚未发生事故。一旦发生事故后果相当严重。

轻者数据泄露，重者商业损失，更严重的导致商誉损失，甚至是企业倒闭。这绝不是危言耸听，且看看这些年来报道的安全门话题，哪个不是损失惨重？

今天就来说一说这个话题：企业应用的Web程序的安全性。

很多企业的应用程序喜欢使用Web来开发，一者开发相对简单，二者部署容易，三者升级方便。所以，Web往往成为企业应用开发的首选。但是由于是企业内部应用，只要不到互联网上就不会把安全当成一会事儿，而且，即使连到互联网上，开发的时候也不会过多考虑安全性。

功能永远在首位，其次是性能，安全~~花钱又多，又看不到效果，反正没出事儿...等等思维方式的影响下，安全话题就在企业开发中被一再搁置，成为一个极少被提及的话题。

然而，企业应用真的就可以忽略安全吗？真的就可以不必在意安全吗？

如果一套工资管理系统，查看工资的代码可以不需要权限就能够直接通过URL访问的话，工资数据就全部泄露了。

如果一套经销商管理系统，定期向经销商发送邮件的服务器并没有设置密码，那么任何人都可以通过这个服务器发送一些匿名邮件。

如果一套销售管理系统，生成订单的URL中没有验证码识别，那么一个机器人就可以生成无数的无效订单。

一套不安全的餐饮管理系统，在一个有WIFI的餐厅里，可能会被某个食客攻击。

一套不安全的生产管理系统（ERP），可能会被工厂里的一台手机控制。

现在的黑客技术越来越多，并不只是银行系统才需要安全机制，也不是加了数字证书Web应用就牢不可破了。

企业Web应用的安全问题不容忽视，也并不容易解决。

那么如何在开发的时候就能够很好地规避安全问题呢？(需求与报价阶段就应该和客户谈清楚，本文从略)

下面从几个能够被攻击的角度进行说明：

1. SQL注入

A. 采用preparedSQL的方式传递参数。

B. 避免社会学猜测，比如密码字段名不叫做password,pswd等容易被猜测的名称。

2. 垃圾数据

A. 后台对于所有的可输入项的数据进行校验，包括采用Radio和DropDown构建的组件。

3.防止URL滥用

A.明确标记GET和POST

4.防止批量删除数据

A. 采用权限校验

B.只提供每次删除一条数据的操作

5. CSRF攻击

A.在HTML代码中书写CSRF禁用代码

          <meta content="authenticity_token" name="csrf-param" />
          <meta content="<<略>>" name="csrf-token" />

 

6.WebService匿名访问

   A. WebService的每个访问都需要经过认证

   B. 每次认证需要有时效性

   C. 认证通过认证码进行

 

7.防止密码泄露

   A. 不在页面显示密码，不在隐含域，HTML注释，JavaScript中显示密码

   B. 不用明文传输密码

   C. 采用较强的密码策略

   D. 不用员工编号作为ID，或者姓名全拼、简拼的方式

   E. 每个人的初试密码不同，并采取暗文抄送的方式

   F. 不提供取回密码功能，只提供更改密码功能，通过有时效的URL进行处理

   G. 不会将密码发送到邮件中去

   H. 不要在Log中记录密码

 

8. 邮件服务器滥用

    A. 必须有用户名密码

    B. 只允许来自固定IP的访问

 

9. 数据库泄露

     A. 删除默认账户

     B. 修改数据库端口

     C. 数据库名称不容易被猜测

     D. 只允许来自固定IP的访问

 

10. 文件未经授权下载

     A. 下载文件的目录不能够通过URL直接访问

     B. 文件下载前必须经过权限认证

 

11. URL泄露

A. 没有权限操作的按钮不显示出来，并且相关的JavaScript也应该不出现

12. StackTrace泄露

A.不要为了维护方便而将Exception的StackTrace输出到页面上