web应用常见安全漏洞

SQL Injection(SQL 注入)

严重性

非常高

概述

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

原理

它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句

例子

程序从Http 请求中读取一个sql 查询，

String sql ="SELECT * FROM accountWHERE name = 'Bob'AND password = '123'" request.getParameter(sql);

...

stmt = conn.createStatement();

...

stmt.execute(sql))

在执行execute()之前，并未进行对字符串sql检查，因此存在SQL 注入弱点。

所以，当在输入密码（password = '123'）之后+加上or '1'='1'则SQL查询语句变为：SELECT * FROM accountWHERE name = 'Bob'AND password = '123'or '1'='1'这样的SQL注入会使得输入任意密码进入程序,这会使WEB程序本身和使用用户产生极大的安全威胁。

后果

?挂蠕虫、木马、病毒、制作钓鱼网站

?操纵受害者的浏览器、盗取用户的cookie/referer/ip等信息

防范

1.永远不要信任用户的输入，要对用户的输入输出进行校验，可以通过正则表达式，或限制长度，或者使用过滤函数，对单引号和双"-"进行转换等。

2.永远不要使用动态拼装SQL，可以使用参数化的SQL或者直接使用存储过程进行数据查询存取。

3.永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。

4. 不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息。

5.应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装，把异常信息存放在独立的表中。

Cross-Site Scripting(跨站点脚本（XSS）) 严重性

非常高

概述

它指的是恶意攻击者往Web页面或者客户端脚本的页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。

原理

Stored XSS（存储式跨站脚本攻击）

这是最强大的一种XSS攻击，所谓存储跨站攻击是指用户提交给Web应用程序的数据首先就被永久的保存在服务器的数据库，文件系统或其他地方，后面且未做任何编码就能显示到Web页面。

Reflected XSS（反射跨站脚本攻击）

当Web客户端提交数据后，服务器端立刻为这个客户生成结果页面，如果结果页面中包含未验证的客户端输入数据，那么就会允许客户端的脚本直接注入到动态页面中。传统的例子是站点搜索引擎，如果我们搜索一个包含特殊HTML字符的字符串时，通常在返回页面

上仍然会有这个字符串来告知我们搜索的是什么，如果这些返回的字符串未被编码，那么，就会存在XSS漏洞了。

DOM-Based XSS（基于DOM的XSS）

这个漏洞往往存在于客户端脚本，如果一个Javascript脚本访问需要参数的URL，且需要将该信息用于写入自己的页面，且信息未被编码，那么就有可能存在这个漏洞。

例子

Stored XSS（存储式跨站脚本攻击）：

后果

如上图所示，不怀好意好意的用户会把恶意代码，如：JavaScript, VBScript, ActiveX, HTML 或Flash等，把它们嵌入到发布的信息中去，然后发送到服务器中，如果服务器没有很好的校验信息，直接把信息转发到用户，这将导致一场XSS攻击灾难。

Reflected XSS（反射跨站脚本攻击）

下面的Java 代码从HTTP Request 中读取一个用户输入、user、再显示给用户

...

out.print(request.getParameter("user"));

...

下面的Jsp 代码从HTTP Request 中读取一个用户输入、user、再显示给用户

...

<%=request.getParameter("user")%>

...

如果可以将未经验证的用户输入直接写入网页，因此这个应用程序就存在跨站点脚本的弱点。设想一下，一个恶意网站使用iframe、连接、图片URL 或表单传送到这个URL ：https://www.360docs.net/doc/8c11474289.html,/insecurepage.jsp?user=admin通过构造带有参数的恶意URL攻击，因为没有验证，所以攻击者可以看到许多网站机密的信息。

后果

机密性：跨站点脚本弱点最严重的后果是储存在用户cookies中的信息外泄。这包括可以让攻击者劫持用户的网络服务进程，并让攻击者能使用该用户的相关帐号。

在某些情况下，有可能迫使用户的浏览器执行恶意代码，将受害用户转到含有恶意内容的其他网页，以便于安装木马或结合其他的弱点以存取本机资料。

例子

DOM-Based XSS（基于DOM的XSS）

如上图所示，攻击者构造一个包含恶意Javascript的URL，然后引诱用户请求这个URL。服务器收到请求后没有返回恶意的Javascript。浏览器在处理URL中的数据时，执行恶意代码。

防范

1.校验用户输入，就是只接受有效的数据，如标头、cookies、查询字符串、表单字段以及隐藏字段等，确认是否是正确的数据，拒绝其他所有数据。

2.HTML编码输出：为了在浏览器中正确地呈现“<”，“>”或空格等文本时，我们需要对其进行编码处理，否则浏览器将根据这些特性文本去执行其功能，而不是正确的呈现在页面上。

Cross Site Request Forgery跨站请求伪造（CSRF）严重性

高

概述

尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。

原理

在用户会话下对某个CGI做一些GET/POST的事情——这些事情用户未必知道和愿意做，你可以把它想做HTTP会话劫持。攻击通过在授权用户访问的页面中包含链接或者脚本的方式工作。

例子

一个网站用户Bob可能正在浏览聊天论坛，而同时另一个用户Alice也在此论坛中，并

且后者刚刚发布了一个具有Bob银行链接的图片消息。设想一下，Alice编写了一个在Bob 的银行站点上进行取款的form提交的链接，并将此链接作为图片tag。如果Bob的银行在cookie中保存他的授权信息，并且此cookie没有过期，那么当Bob的浏览器尝试装载图片时将提交这个取款form和他的cookie，这样在没经Bob同意的情况下便授权了这次事务。

CSRF是一种依赖web浏览器的、被混淆过的代理人攻击（deputy attack）。在上面银行示例中的代理人是Bob的web浏览器，它被混淆后误将Bob的授权直接交给了Alice使用。

后果

获得管理员权限。盗取用户银行卡、信用卡信息。授信用户被提交恶意数据、被执行恶意操作。

防范

1.服务器区分GET/POST，增加攻击难度

2.REFERER校验，补充手段

3.改长授信为短授信。时间戳、关键流程使用验证码、Token验证

错误认证和会话管理

(Session Variable Poisoning)

严重性

中

概述

“遭破坏的认证和会话管理”，简而言之，就是攻击者窃听了我们访问HTTP时的用户名和密码，或者是我们的会话，从而得到sessionID，进而冒充用户进行Http访问的过程。

原理

由于HTTP本身是无状态的，也就是说HTTP的每次访问请求都是带有个人凭证的，而SessionID就是为了跟踪状态的，而sessionID本身是很容易在网络上被监听的到，所以攻击者往往通过监听sessionID来达到进一步攻击的目的。

错误的认证：窃取用户名、密码。明文传输。认证漏洞。

会话管理：窃取会话的SessionId，冒充真正用户进行web应用访问。

防范

第一，我们要整体审视我们的架构

●认证机制本身必须是简单、集中和标准化的；

●使用容器提供给我们的标准session id；

●确保在任何时候用SSL来保护我们的密码和session id

第二，验证认证的实现机制

●检查SSL的实现方法

●验证所有与认证相关的函数

●确保“注销登录”的动作能够关闭所有的会话

未验证的重定向和传递(Open Redirect)

概述

在Web应用中重定向是极为普遍的，并且通常重定向所引向的目的是带有用户输入参数的目的URL，而如果这些重定向未被验证，那么攻击者就可以引导用户访问他们所要用户访问的站点。

原理

转发是在同一个应用中对一个新页面发送请求，并且有时是用参数来定义目标页面的。同样，如果参数未被验证，那么攻击者就可以利用其来绕过认证或是授权检查。

后果

而最终造成的后果，重定向会使得用户访问钓鱼网站或是恶意网站，而转发则会让攻击者利用先前安全检查过的请求来绕过认证或是授权。

1. 尽可能的避免使用重定向和转发机制；

2. 如果使用了，那么在定义目标url的时候不要包含用户参数；

3. 如果一定要包含用户的参数，那么，对每个参数都必须进行验证以确保它的正确性和合法性；或是在服务器端提供映射机制，将用户的选择参数转变为真正的目标页面；

HTTP 应答分割(HTTP Response Splitting) 严重性

中

概述

发生在未经验证的数据被写入HTTP标头时，这样可能会允许攻击者获取指定的浏览器提供的HTTP相应的全部数据。

原理

HTTP 应答分割弱点可能发生在出现下列情况时：

数据由不被信任的来源进入网络应用程序，大多是通过HTTP请求。

这样的数据被加入到HTTP应答的标头中，并且在没有被检查是否含有恶意字符的情况下，传送给用户。

后果

可信度：HTTP应答分割可以用来篡改HTTP应答。

认证：HTTP应答分割可以用来复写cookies 并绕过认证。

防范

最佳的解决办法就是验证输入。在送入HTTP应答标头之前（尤其是设定cookies 和重新导向时）将CR 和LF （包括其他所有的有害的字符）移除。也可以使用第三方产品对CR 及LF 进行防护，或者是在部署应用程序前测试是否存在这样的弱点。

不安全的加密存储

严重性

中

概述

加密有助于防止他人查看敏感数据，而且可提供监测数据是否已被修改的用加密算法对数据进行加密，在加密状态传输数据，然后由预定的接收方对数据进行解密。

原理

1. 未能识别全部的机密数据；

2. 对某个机密数据未能识别其所有的存放地；（数据库、文件、目录、日志文件……）

3. 未对数据的每个存放地进行合理的保护

后果

1.攻击者能够取得或是篡改机密的或是私有的信息；

2. 攻击者通过这些秘密的窃取从而进行进一步的攻击；

3. 造成企业形象破损，用户满意度下降，甚至会有法律诉讼等；

防范

1.验证你的结构

识别所有的敏感数据；识别这些数据存放的所有位置；确保所应用的威胁模型能够应付这些攻击；使用加密手段来应对威胁

2.使用一定的机制来进行保护

文件加密；数据库加密；数据元素加密

3.正确的使用这些机制

使用标准的强算法；合理的生成，分发和保护密钥；准备密钥的变更

4.验证实现方法

确保使用了标准的强算法；确保所有的证书、密钥和密码都得到了安全的存放；有一个安全的密钥分发和应急处理的方案；

安全误配置（Security Misconfiguration）严重性

中

概述

Web服务器位于宿主基础结构的前端。它可以直接连接到Internet，负责接收来自客户端的请求、创建动态Web页面并对请求的数据做出相应。安全的Web服务器可为宿主的环境提供可靠的基础、对整个安全方面其重要作用。

后果

安全误配置往往使得攻击者能够访问未被授权的系统数据和功能，甚至有时，会导致整个系统被破坏。

防范

问题可能存在于Web应用的各个层次，譬如平台、Web服务器、应用服务器，系统框架，甚至是代码中。开发人员需要和网络管理人员共同确保所有层次都合理配置.。

一些注意事项

文件上传

Web应用程序在处理用户上传的文件时，没有判断文件的扩展名是否在允许的范围内，或者没检测文件内容的合法性，就把文件保存在服务器上，甚至上传脚本木马到web服务器上，直接控制web服务器。

1. 未限制扩展名

2. 未检查文件内容

3. 病毒文件

不恰当的异常处理

程序在抛出异常的时候给出了比较详细的内部错误信息，暴露了网站存在潜在漏洞；