BS开发中遇到的安全隐患和对应措施

你的名字 2020-11-01 08:06 884阅读 0赞

**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） 用户的输入内容如果直接以文本的形式输出到页面的话，对以下字符进行转义。

「&」  ⇒　「&」   
             「<」  ⇒　「<」   
             「>」  ⇒　「>」   
             「"」  ⇒　「"」  
             「'」  ⇒　「&\#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" />
```