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

提起安全性这个话题,你们恐怕依稀还记得Sony的PSP帐户信息泄露的事故形成的重大损失。可是又隐隐以为这事儿离我很远,无需过多考虑。也有的人会想,咱们作的是企业内部系统因此没必要太在乎。可是,Web程序的安全性已经悄然来到你我身边,咱们在使用的系统太多的并无充分考虑安全性。这样的系统只是还没有发生事故。一旦发生事故后果至关严重。数据库

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

今天就来讲一说这个话题:企业应用的Web程序的安全性。服务器

不少企业的应用程序喜欢使用Web来开发,一者开发相对简单,两者部署容易,三者升级方便。因此,Web每每成为企业应用开发的首选。可是因为是企业内部应用,只要不到互联网上就不会把安全当成一会事儿,并且,即便连到互联网上,开发的时候也不会过多考虑安全性。性能

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

然而,企业应用真的就能够忽略安全吗?真的就能够没必要在乎安全吗?token

 

若是一套工资管理系统,查看工资的代码能够不须要权限就可以直接经过URL访问的话,工资数据就所有泄露了。ip

若是一套经销商管理系统,按期向经销商发送邮件的服务器并无设置密码,那么任何人均可以经过这个服务器发送一些匿名邮件。ci

若是一套销售管理系统,生成订单的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输出到页面上

相关文章
相关标签/搜索