BS开发中遇到的安全隐患和对应措施 （不定时更新）

SQL注入攻击（SQL injection）

危害度：  高

通常原因：
直接使用页面输入的内容来拼接组建SQL文。
例如：
String sql = "DELETE FROM member WHERE email = '" + email + "' AND password = '" + password + "'";
如果传入一下输入以下数据的话
email = "test@test.com"
password = "' or 1 = 1"
组建的SQL就会变成
sql = "DELETE FROM user WHERE email = 'test@test.com' AND password = '' or 1 = 1
解决对策：
现在的大多数Web开发框架都集成了这一问题的自动解决方案。如果在项目中使用了框架的话，
除非是特殊的检索，否则，自己不用再额外做什么应对措施的。
如果没有使用框架的话，那么可以采取两个对策。
（1）对于用户输入做严格验证，比如数字、日期之类的合法性等，这个有助于减少隐患。
（2）在拼接组建SQL文的时候，对特殊文字进行escape。需要转义字符因数据库而不同，一般都会包括： ' => '' 和 \ => \\

跨站脚本攻击（Cross Site Scripting，缩写XSS）

危害度： 中

通常原因：

程序中，直接将用户的输入数据显示到页面上。

例如：在某论坛，有恶意用户A发布带脚本的帖子，由于输入数据原样显示在页面中，所以显示页面的时候该脚本可执行。

此时，如果用户B浏览到该网页时，用户B的就会受到侵害，如个人信息泄露，遭受病毒、木马等。

此类问题容易出现在论坛社交类网站。（没事还是少上不正规的黄色论坛的好！！）

解决策略：

  （1） 用户的输入内容如果直接以文本的形式输出到页面的话，对以下字符进行转义。

             「&」  ⇒　「&」 
             「<」  ⇒　「&lt;」 
             「>」  ⇒　「&gt;」 
             「"」  ⇒　「&quot;」
             「'」  ⇒　「&#39;」           PS： 这个不转义其实也没事

  （2） 用户的输入内容如果作为标签属性输出的话，一定要包含到引号里。

 PS：应该在项目开始之初就定制成通用方案，并且在今后的项目中重复利用。

换行符注入攻击（或者叫“HTTP header 注入攻击”， 英文：HTTP Header Injection）

危害度： 中

通常原因：

      程序里直接将用户输入数据作为response的一部分内容返回给用户了。此时，如果用户的输入数据包含了换行符的话，就可以恶意篡改HTTP信息，如cookie等。

      例如：

         通过如下URL访问网站

         http://www.test.com/?a=%0d%0aSet-Cookie:%20userId%3d999

         如果程序里直接在response.sendRedirect的URL里使用参数a的值的话，用户cookie里的数据就会篡改。

解决策略：

    （1）加强参数的合法性检查

    （2）用户的输入参数在response的field里使用之前，去除换行符。

使用HTTP协议传输重要信息或者用户个人信息。

危害度： 中

解决策略：

      使用SSL协议（即HTTPS）传输重要信息或者用户个人信息。

访问地址被任意导向

危害度： 低

通常原因：

    当通过参数来传递url时，参数值被恶意篡改的话，用户就会恶意导向一些别的网站（如含有病毒或木马的网站）。

    例如：程序对如下URL的处理后，会返回returnUrl的页面

         http://www.test.com/login?returnUrl=xxxxxxx

         如果returnUrl被恶意篡改的话，用户就会被导向恶意网站。

解决策略：

        （1）加强参数的合法性检查，如domain等

        （2）对参数值进行加密

暴露服务器IP

危害度： 低

通常原因：

    当apache的VirtualHost里的ServerName没设置成domain时，

    请求头里Host项目去掉后的HTTP1.0请求访问网站时，response信息的Location里会暴露服务器的IP，有可能招致更多别的攻击。

    PS:HTTP1.0请求才有这问题，HTTP1.1的请求Host项是必须的，没有的话报400 Bad Request错误。

解决策略：

     apache的VirtualHost里的ServerName没设置成domain

未防止CSRF伪造请求

危害度： 中

通常原因：

     对于客户端提交的表单没有防伪造的防范。

     恶意用户可以伪造请求提交；后者普通用户受到CSRF攻击时被提交。

     从而造成服务器负荷严重而宕机或者造成用户的个人损失。

解决策略：

     （1）在表单里增加用于验证的随机数hidden

     （2）使用认证码CAPTCHA

     （3）对请求头的Referer进行合法性验证，判断提交前的页面是否为站内页面

Cookie的HttpOnly没有设置为true

危害度： 中

通常原因：

     HttpOnly没有设置为true的cookie数据，允许被JavaScript脚本访问，如果遭到跨站脚本攻击的话，

     用户的cookie数据就有可能暴露。

解决策略：

     （1）在服务器配置文件里统一配置。如Tomcat的server.xml的userHttpOnly="true"。

     （2）代码里网Cookie里存数据时，指定HttpOnly为true。

系统发生异常时暴露代码细节

危害度：小

通常原因：

      代码里对没有预期的异常没有作统一的处理。直接抛出到页面了。

解决策略：

     系统的异常处理设计时，对未预期的异常进行捕获，页面输出特定信息。

未防止点击劫持（clickjacking）的请求

危害度：小

通常原因：

      一些恶意网站隐藏提交目标为本网站的iframe，用户访问这些恶意网站时遭受点击劫持提交了表单的话，

      会产生用户购买或注销等行为。

解决策略：

      通过代码或服务器配置，设置X-Frame-Options项，禁止或者只允许相同domain的frame请求。

      如apache里添加  Header always append X-Frame-Options SAMEORIGIN

浏览器保存了重要信息的缓存

危害度：小

通常原因：

      一些显示重要信息或者用户个人信息的页面，没有设置清除缓存。

解决策略：

页面里添加如下tag或者直接后台代码里设置response里的这三项。

<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Expires" content="Fri, 1 Jan 2010 00:00:00 GMT" />