常见HTTP攻与防

1. header name和value中出现CRLF字符

在header中嵌入CRLF（回车换行）字符是一种常见的攻击手段。攻击者嵌入CRLF以后，使服务器对HTTP请求发生错误判断，从而执行攻击者的恶意代码。事实上，现在的servlet引擎如tomcat已经可以防御这种攻击。

当然，有的应用服务器还不可以防御，所以，可能通过增加过滤器类似技术来进行处理，避免此类攻击。
2. status message嵌入恶意代码

 通常status message会被显示在HTML页面中。攻击者可以利用这一点在页面中嵌入恶意代码。将status message以HTML entity编码重写以后，就可以避免这个问题。

可以通过过滤器相关技术进行防御

3. cookie过大

过大的cookie可能使WEB服务器拒绝响应请求。攻击者同样可以
利用这一点使用户无法正常访问网站。限制cookie的总大小可以部分地解决这种危机。

可能在服务器端设置最大Cookie大小进行限制

4. XSS攻击(跨站脚本攻击)

恶意web用户将代码植入到提供给其它用户使用的页面中。比如这些代码包括HTML代码和客户端脚本。攻击者利用XSS漏洞旁路掉访问控制——例如同源策略(same origin policy)。这种类型的漏洞由于被骇客用来编写危害性更大的phishing攻击而变得广为人知。对于跨站脚本攻击，黑客界共识是：跨站脚本攻击是新型的“缓冲区溢出攻击“，而JavaScript是新型的“ShellCode”。

这个需要对输出的内容根据情况进行处理，避免其录入Script/iframe代码，就可以避免，也就是说对于不可信任的人永远不要允许其录入危险代码或者在输出的时候把危险代码过滤掉比如把<script>  <iframe>等都 替换成&lt;script&gt; &lt;iframe&gt;。

5.CSRF攻击（跨站请求伪造）

攻击者通过各种方法伪造一个请求，模仿用户提交表单的行为，从而达到修改用户的数据，或者执行特定任务的目的。为了假冒用户的身份，CSRF攻击常常和XSS攻击配合起来做，但也可以通过其它手段，例如诱使用户点击一个包含攻击的链接。

解决方案：

1，通过CSRF token，可以确保该请求确实是用户本人填写表单并提交的，而不是第三者伪造的，从而避免CSRF攻击。CSRF token验证器是用来确保表单中包含了CSRF token。
2，执行重要业务之前，要求用户提交额外的信息。要求用户在进行重要业务前输入口令，这可以防止黑客发动CSRF攻击（只要浏览器中没有包含口令），因为这种重要信息无法预测或轻易获得。
3，使用秘密的无法预测的验证符号。当保存在用户浏览器中的cookie仅由一次会话确认时，CSRF攻击才会有效。所以在每次HTTP请求（当然攻击者无法提前知道）中都有附加的特定会话的信息，这样就可以挫败CSRF攻击。不过，如果这种应用程序存在跨站脚本漏洞，黑客就有可能访问这种验证符号。
4，使用定制的HTTP报头。如果执行交易的所有请求都使用XMLHttpRequest并附加一个定制的HTTP报头，同时拒绝缺少定制报头的任何请求，就可以用XMLHttpRequest API来防御CSRF攻击。由于浏览器通常仅准许站点将定制的HTTP报头发送给相同站点，从而了防止由CSRF攻击的源站点所发起的交易。
5，检查访问源的报头。在浏览者发送HTTP请求时，它通常会包含源自访问源报头的URL。理论上讲，你可以使用这些信息来阻止源自其它任何站点（而不是来自Web应用程序自身）的请求。不过，访问源报头并不总是可用的，（例如，有些单位由于私密性的缘故而将它剥离了），或者这个报头容易被欺骗，所以说，这条措施并不真正有效。

6. SQL注入

就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令

解决方案：永远不要使用客户端输入的内容进行SQL拼接，取而代字用占位符替换的方式；或者对客户输入的内容过滤及合法性检查。

实际上我们经常会犯这些错误：

比如1，许多是没有检测的，完全依赖于应用服务器

比如xss，上次就被客户找的安全公司检测出来(这些输出本来是要有一层特殊字符过滤的，但是为了省事，没有添加，就出现了此问题)

比如，sql注入，上次就被客户找的安全公司检测出来(本来都是要求用PrepareStatement进行处理的，但是程序员为省事就直接字符串连接了)

所以，我们原来是在做局域网的应用，有点安全漏洞因为攻击者在防火墙外边，接触不到，所以，可能问题不大。目前我们的业务越来越多暴露在广域网上，所以，这方面需要加强力量，严格重视。不要因为我们无知，就无畏。