1、 必须考虑意外情况并进行处理 不要试图在发现错误之后继续执行 尽可能使用安全函数进行编程 小心、认真、细致地编程5 Web应用程序常见安全问题下面的安全问题是根据应用程序漏洞类别描述的。实际经验表明，如果这些领域的设计存在薄弱环节，将会导致安全漏洞。下表列出了漏洞的类别，每个类别都突出显示了由于设计不当可能会导致的潜在问题。漏洞类别由于设计不当而引起的潜在问题输入验证嵌入到查询字符串、表单字段、cookie和HTTP头中的恶意字符串的攻击。这些攻击包括命令执行、跨站点脚本（XSS）、SQL输入和缓冲区溢出攻击。身份验证标识欺骗、密码破解、特权提升和XX的访问。授权访问保密数据或受限数据、篡改数
2、据以及执行XX的操作。配置管理对管理界面进行XX的访问、具有更新配置数据的能力以及对用户账户和账户配置文件进行XX的访问。敏感数据泄漏保密信息以及篡改数据。会话管理捕捉会话标识符，从而导致会话劫持及标识欺骗。加密访问保密数据或者账户凭据，或者二者均能访问。参数操作路径遍历攻击、命令执行以及绕过访问控制机制，从而导致信息泄漏、特权提升和拒绝服务。异常管理拒绝服务和敏感的系统级详细信息的泄漏。审核和记录不能发现入侵迹象、不能验证用户操作，以及在诊断问题时出现困难。5.1 跨站脚本攻击5.1.1 定义什么是跨站脚本攻击：跨站脚本攻击（通常简写为XSS）是最普通的web应用安全漏洞，当应用程序在发送给
3、浏览器的页面中包含用户提供的数据，没有经过严格验证或转义，那么攻击者就有可能利用网站程序对用户输入过滤不严，输入可以显示在页面上对其他用户造成影响的HTML代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。5.1.2 危害 敏感数据被获取（cookie盗取） 网络钓鱼 获取web用户的网页内容 Session Riding（CSRF攻击） 获取用户的键盘击键数据 Web僵尸 XSS蠕虫攻击者能在受害者浏览器中执行脚本以劫持用户会话、迫害网站、插入恶意内容、重定向用户、使用恶意软件劫持用户浏览器等等。入侵者便通过技术手段在某个页面里插入一个恶意HTML代码，
4、例如记录论坛保存的用户信息（Cookie），由于Cookie保存了完整的用户名和密码资料，用户就会遭受安全损失。如这句简单的javascript脚本就能轻易获取用户信息：alert（document.cookie），它会弹出一个包含用户信息的消息框。入侵者运用脚本就能把用户信息发送到他们自己的记录页面中，稍作分析便获取了用户的敏感信息。跨站脚本攻击的危险，在如今WEB安全越来越得到重视，他的危险性也越来越大。有效防止跨站脚本攻击，是WEB程序是否安全的一个重要标准。5.1.3 解决方法主要防御方式5.1.3.1 验证输入验证输入很简单，检查每个输入的有效性。这可能意味着很多东西，但在典型的和简
5、单的情况下，这意味着检查输入类型和数据的长度。例如，如果你是从一个文本框接受一个标准的邮政编码，你会知道，唯一有效的类型是一个数字（0-9），而长度应该是6，不能多也不能少。并非所有的案例都如此简答，但很多是相似的。下图显示验证输入的架构。这里的关键是，一切都进行验证，所有的输入，这并不来自于应用程序（包括用户输入，请求头，Cookie，数据库数据）。5.1.3.2 编码输出对于不支持HTML代码的地方，可用编码输出。如：Server.UrlEncode等方法编码输出。优点：安全可靠。缺点：不支持HTML代码。对于验证输入的另一面就是编码输出。编码输出，是用来确保字符被视为数据，而不是作为HT
6、ML元字符被浏览器解析。这些技术定义一些特殊的“转义”字符。没有正确转义的数据它仍然会在浏览器中正确解析。编码输出只是让浏览器知道数据是不是要被解析，达到攻击无法实现的目的。需要编码的部分：HTML实体HTML属性JavascriptCSSURL5.1.3.3 辅助防御方式防御手段一：iframe security=“restricted”保护级别：描述：通过设置iframe security=“restricted”，能有效防止iframe类的攻击（对IE有效）。有效防止iframe的攻击。防御手段二：HttpOnly设置Cookie的HttpOnly属性，有效地防止Cookie通过脚本泄密
7、（IE6 SP1以上、Firefox3）。有效保护了用户的Cookie信息。应用举例： 系统中，所有登录验证的地方，验证成功后设置authCookie.HttpOnly=true,设置Cookie的HttpOnly属性，这些都应用于用户登录成功的地方。防御手段三：字符过滤通过函数进行过滤，能有效防止常见跨站脚本的跨站攻击。主要过滤常见恶意脚本代码，如：applet|meta |xml |blink|link|style|script|embed|object|iframe|frame|frameset|ilayer |layer|bgsound |title|baseOnX事件代码、Javas
8、cript、Vbscript和Style中的expression、behaviour、script、position等。但过滤可能存在不完全的情况。建立自己的XSS攻击库，方便测试和收集新的攻击方式，使过滤函数更加完善。支持HTML，有效防止大部分攻击代码。可能存在过滤不全的情况。5.2 SQL注入5.2.1 定义什么是SQL注入所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。通过递交参数构造巧妙的SQL语句，从而成功获取想要的数据。简单来说，注入往往是应用程序缺少对输入进行安全性检查所引起的，攻击者把一些包含指
9、令的数据发送给解释器，解释器会把收到的数据转换成指令执行，注入漏洞十分普遍，通常能在SQL查询、程序参数等中出现。下图为SQL攻击原理图：5.2.2 危害注入能导致数据丢失或数据破坏、缺乏可审计性或是拒绝服务。注入漏洞有时甚至能导致完全接管主机，主要危害有以下几点： 绕过防火墙进行攻击 绕过web应用程序的验证过程 非法越权操作数据库内容 随意篡改网页内容 添加系统账户或数据库账户 上传和下载非法文件 本地溢出并获取系统最高权限 安装木马后门/僵尸网络5.2.3 解决方法SQL注入实例：String sqlString=“SELECT * FROM users WHERE fullname=”
10、+form.getFullName（）+”AND password=” +form.getPassword（）+ “”;正常：username=tony，password=123456SELECT * FROM users WHERE username=tony AND password=123456攻击：username=tony，password= OR 1=1SELECT *FROM users WHERE username=tony AND password= OR 1=1参数化查询预处理对于JDBC而言，SQL注入攻击只对Statement有效，对PreparedStatement是
11、无效的，这是因为PrepareStatement不允许在不同的插入时间改变查询的逻辑结构。如验证用户是否存在的SQL语句为：select count（*） from usertable where name=用户名 and pswd=密码如果在用户名字段中输入or 1=1 or 1=1或是在密码字段中输入1 or 1=1将绕过验证，但这种手段只对Statement有效，对PreparedStatement无效，PreparedStatement相对Statement有以下优点： 防注入攻击 多次运行速度快 防止数据库缓冲区溢出 代码的可读性可维护性好5.3 恶意脚本执行5.3.1 定义恶意文件
12、执行是一种能够威胁任何网站形式的漏洞，只要攻击者在具有引入（include）功能程式的参数中修改参数内容，WEB服务器便会引入恶意程序内容从而收到恶意文件执行漏洞攻击。5.3.2 危害攻击者可利用恶意文件执行漏洞进行攻击取得WEB服务器控制权，进行不法利益或获取经济利益。5.3.3 解决方法 验证输入，验证上传文件名 检查上传文件的大小5.4 文件上传漏洞5.4.1 定义Web应用程序在处理用户上传的文件时，没有判断文件的扩展名是否在允许的范围内，就把文件保存在服务器上，导致恶意用户可以上传任意文件，甚至上传脚本木马到web服务器上，直接控制web服务器。5.4.2 危害攻击者可利用文件上传功
13、能，上传Webshell从而控制整个主机系统。5.4.3 解决方案 检查上传文件扩展名白名单，不属于白名单内，不允许上传。 上传文件的目录必须是http请求无法直接访问到的。如果需要访问的，必须上传到其他（和web服务器不同的）域名下，并设置该目录为不解析jsp等脚本语言的目录。 上传文件要保存的文件名和目录名由系统根据时间生成，不允许用户自定义。 图片上传，要通过处理（缩略图、水印等），无异常后才能保存到服务器。 上传文件需要做日志记录，请参照“Error Handing and Logging章节”。5.5 传输敏感信息未使用安全通道5.5.1 定义对于未加密的敏感数据在网络上传输时，需要
14、使用安全的通道。否则应用程序将暴露身份验证或会话令牌。5.5.2 危害 攻击者能够取得或者篡改机密的或是私有的信息； 攻击者通过这些私密信息的窃取从而进行进一步的攻击； 造成企业形象破损，用户满意度下降，甚至会有法律诉讼等。5.5.3 解决方案 提供合理的保护机制； 对于敏感数据的传输，对所有连接都要使用TLS； 在传输前对单个数据都要进行加密；（如XML-Encryption） 在传输前对信息进行签名；（如XML-Signature） 正确的使用这些机制； 使用标准的强加密算法； 合理管理密钥和证书； 在使用前验证SSL证书；5.6 信息泄漏和错误处理不当5.6.1 定义应用程序没有统一的异
15、常处理页面，导致敏感信息泄漏，常常产生错误信息并显示给使用者。很多时候，这些错误信息是非常有利于攻击者发起攻击，因为他们揭示实施细节或者对利用漏洞有用的开发信息。示例：看到此信息，攻击者可以做以下判断：a） 数据库是oracleb） 查询语句的列数不正确根据这个判断，攻击者调整get请求的内容，最终达到获取数据库所有数据的目的。5.6.2 危害 泄漏太多细节（如错误堆栈跟踪信息、SQL语句等等）； 登录失败后，通知用户是否用户ID或密码出错-登录失败可能是由于ID或密码错误造成的。这为一个对关键资产发动暴力破解的攻击者提供重要信息。5.6.3 解决方案 通过web.xml配置文件实现，产生异常
16、或者错误时跳转到统一的错误处理页面，避免泄漏过多敏感信息。 exception-type/exception-typelocation/error.jsp/error-page 针对登录尝试的攻击，如果输入用户名或者是口令错误，可以使用相同的报错信息，比如都提示“输入用户名或密码错误！”。5.7 跨站请求伪造5.7.1 定义Cross-Site Request Forgery（CSRF），跨站请求伪造攻击。攻击者在用户浏览网页时，利用页面元素（例如img的src），强迫受害者的浏览器向Web应用程序发送一个改变用户信息的请求。5.7.2 危害由于发生CSRF攻击后，攻击者是强迫用户向服务器发送
17、请求，所以会造成用户信息被迫修改，更严重者引发蠕虫攻击。CSRF攻击可以从站外和站内发起。从站内发起CSRF攻击，需要利用网站本身的业务，比如“自定义头像”功能，恶意用户指定自己的头像URL是一个修改用户信息的链接，当其他已登录用户浏览恶意用户头像时，会自动向这个链接发送修改信息请求。从站外发送请求，则需要恶意用户在自己的服务器上，放一个自动提交修改个人信息的html页面，并把页面地址发给受害者用户，受害者用户打开时，会发起一个请求。如果恶意用户能够知道网站管理后台某项功能的URL，就可以直接攻击管理员，强迫管理员执行恶意用户定义的操作。5.7.3 代码示例一个没有CSRF安全防御的代码如下：
18、代码中接收用户提交的参数“email,tel,realname”，之后修改了该用户的数据，一旦接收到一个用户发来的请求，就执行修改操作。提交表单代码：当用户点提交时，就会触发修改操作。5.7.4 解决方案要防御CSRF攻击，必须遵循一下三步：1、 在用户登陆时，设置一个CSRF的随机TOKEN，同时种植在用户的cookie中，当用户浏览器关闭、或用户再次登录、或退出时，清除token。2、 在表单中，生成一个隐藏域，它的值就是COOKIE中随机TOKEN。3、 表单被提交后，就可以在接收用户请求的web应用中，判断表单中的TOKEN值是否和用户COOKIE中的TOKEN值一致，如果不一致或没有
19、这个值，就判断为CSRF攻击，同时记录攻击日志（日志内容见“Error Handing and Logging”章节）。 由于攻击者无法预测每一个用户登录时生成的那个随机TOKEN值，所以无法伪造这个参数。代码中$csrfToken.hiddenField将会生成一个隐藏域，用于生成验证token，它将会作为表单的其中一个参数一起提交。5.8 访问控制缺陷5.8.1 权限提升5.8.1.1 定义访问控制过程中身份验证有缺陷，导致用户越权访问信息。5.8.1.2 危害由于web应用程序没有做权限控制，或仅仅在菜单上做了权限控制，导致的恶意用户只要猜测其他管理页面的URL，就可以访问或控制其他角色
20、拥有的数据或页面，达到权限提升目的。这个威胁可能导致普通用户变成管理员权限。5.8.1.3 代码示例一个仅仅做了菜单控制的代码：恶意用户，可以直接猜测“管理所有用户”的页面，通过URL访问，看到管理员页面。5.8.1.4 解决方案在打开管理页面URL时，首先判断当前用户是否拥有该页面的权限，如果没有权限，就判定为“权限提升”攻击，同时记录安全日志。建议使用成熟的权限框架处理权限问题，比如spring security。5.8.2 不安全的直接对象引用5.8.2.1 定义所谓“不安全的直接对象引用”，指的是一个已经授权的用户，通过更改访问时的一个参数，从而访问到原本并没有得到授权的对象。Web应
21、用往往在生成Web页面时会用它的真实名字，且并不会对所有的对象访问时来检查用户权限，所以这就造成不安全的对象直接引用漏洞。我们看如下的一个示例，也许这样就更容易理解什么是不安全的对象直接引用。 攻击者发现他自己的参数是6065，即acct=6065; 他可以直接更改参数为6066，即acct=6066; 这样他就可以直接看到6066用户的账户信息。5.8.2.2 危害这种漏洞损害参数所引用的所有数据。除非名字空间很稀疏，否则攻击者很容易访问该类型的所有数据。或者恶意用户可以删除或修改其他人数据。5.8.2.3 代码示例以下代码存在这个漏洞，web应用在修改用户个人信息时，从从用户提交的requ
22、est参数（用户可控数据）中，获取了userid，执行修改操作。修改用户个人信息页面：表单中，将用户的userid作为隐藏字段，提交给处理修改个人信息的应用。下面代码是修改个人信息的应用：这段代码是从request的参数列表中，获取userid，也就是表单提交上来的userid，之后修改userid对应的用户数据。 而表单中的userid是可以让用户随意修改的。5.8.2.4 解决方案 从用户的加密认证cookie中，获取当前用户的id，并且需要在执行的SQL语句中，加入当前用户id作为条件语句。由于是web应用控制的加密算法，所以恶意用户无法修改加密信息。示例代码：代码中通过GetUseri
23、dFromCookie，从加密的COOKIE中获取了当前用户的id，并加入到SQL语句中的WHERE条件中。5.9 不安全的加密5.9.1 定义系统中涉及到敏感信息的数据直接明文存储，极不安全，需要加密存储。或者采用程序员自己编写的“简单算法”加密，一旦被人获取足够的“样本”，将有可能被反向推测出解密算法，从而泄露重要信息。一些低强度的密码算法，如DES、RC2等已经可以很容易的在短时间内被人所破解，其它一些容易被误用的“密码算法”，如base64、escape、urlencode等，其实并不是密码算法，只是简单的编码而已，不能起到密码算法保护信息的作用。5.9.2 弱加密示例线性加密算法，下
24、面以“古典密码算法”为例：该算法对字符串做“Offset”位偏移，极易被破解，不宜采用。5.9.3 解决方案详见6.3。5.10 限制URL访问失效URL中或者其他参数包含文件、目录、数据库记录或者关键字等参照物，导致接口处信息泄露。5.10.1 定义这个漏洞事实上也是与认证相关的，与我们前面提到的不安全的直接对象引用也是类似的，不同在于这个漏洞是说系统已经对URL的访问做限制，但这种限制却实际并没有生效。常见的错误是，我们在用户认证后只显示给用户认证过的页面和菜单选项，而实际上这些仅仅是表示层的访问控制而不能真正生效，攻击者能够很容易的就伪造请求直接访问未被授权的页面。我们举个例子来说明这个
25、过程： 攻击者发现他自己的访问地址为/user/getAccounts; 他修改他的目录为/admin/getAccounts或/manager/getAccounts; 这样攻击者就能够查看到更多的账户信息。5.10.2 解决方案对每个URL，我们必须做三件事： 如果这个URL不是公开的，那么必须限制能够访问他的授权用户 加强基于用户或者角色的访问控制； 完全禁止访问未被授权的页面类型（如配置文件、日志文件、源文件等） 验证架构 在每一个层次都使用简单肯定的模型； 确保每一层都有一个访问机制。 验证实现 不要使用自动化分析工具； 确保每个URL都被外部过滤器或其他机制保护； 确保服务器的配置
26、不允许对非授权页面的访问。5.11 Session管理5.11.1 Cookie http only flag5.11.1.1 定义Cookie http only，是设置COOKIE时，可以设置的一个属性，如果COOKIE没有设置这个属性，该COOKIE值可以被页面脚本读取。当攻击者发现一个XSS漏洞时，通常会写一段页面脚本，窃取用户的COOKIE，为了增加攻击者的门槛，防止出现因为XSS漏洞导致大面积用户COOKIE被到，应该在设置认证COOKIE时，增加这个属性。5.11.1.2 代码示例这段代码没有设置http only属性：response.setHeader（SET-COOKIE,
27、 user= + request.getParameter（cookie）;5.11.1.3 解决方案设置cookie时，加入属性即可：） + ; HttpOnly）;下图可以看到cookie已经加入了httponly属性：5.11.1.4 常见问题 如何在COOKIE类中设置httponly？ 目前的jdk版本只支持在setHeader时，设置httponly。 Httponly已经可以防止用户COOKIE被窃取，还需要做XSS防御吗？ 这个flag只能增加攻击者的难度，不能达到完全防御xss攻击。5.11.2 Cookie Secure flag5.11.2.1 定义Cookie Secure，是设置COOKIE时，可以设置的一个属性，设置了这个属性后，只有在https访问时，浏览器才会发送该COOKIE。浏览器默认只要使用http请求一个站点，就会发送明文COOKIE，如果网络中有监控，可能被截获。如果Web应用网站全站是https的，可以设置COOKIE加上Secure
