一、前言
本文旨在告诉读者如何去发现和利用潜藏在WEB应用程序中的安全漏洞。懂得这些安全漏洞是如何产生的，才能让我们在防护的过程中得心应手。这当中，我会试着把一些背景知识，理论，小工具等等东西都介绍给大家。安全意识从来都是一把双刃剑—-针对应用程序的开发者和黑客们!开发者从中知道黑客是如何黑进他们的系统的，而黑客也紧跟开发者的脚本学习到了开发上的知识，促使一系列的技术更新和完善。总而言之，黑客和开发者之间的战斗永不停歇，这场战斗至少促成一种东西叫：进步!
回头看看早期的WEB站点，可能没几个人真正了解过，除了放几个静态的html页面。再看看今天流行的WEB页面，或者我称呼它为WEB应用程序比较贴切。它具备多功能，动态交互，注册和登陆的高级使用功能，配合服务器端的WEB有类似专门的浏览器。您可曾想过，这当中的大部分交互和保留的信息中，大部分都是私有和敏感的信息呢。所以安全的确是一个大问题啊。
寻找WEB应用程序，我觉得首先应该看看是谁开发了这套程序。举例来说：如果您已找到我网站上面有XSS的漏洞，那么您几乎可以在我的写的其他WEB代码上找到类似的漏洞(想看看我的站吗?后面有留我的网址)。 换句话说：如果我在WEB程序上犯了一个开发错误(却一直没有去纠正过它)，那说明我没有足够的能力去修复和意识到这个问题。这极有可能导致我还会在其他WEB开发中犯下同样的错误。
二、常见的WEB应用场景
(1) 购物 (京东网)
(2) 社交网络(人人网)
(3) 银行(招商银行)
(4) 搜索 (百度)
(5) 拍卖 (淘宝)
(6) 博客 (百度博客)
(7) 电子邮件 (网易EMAIL)
(8) 交互信息 (互动百科)
这些场景，只是举例。随着时代的进步，玩转这些服务需要一个过程!但在这个过程中，人们逐渐把自己需要使用的服务迁移到这些WEB应用程序上面。比如，把微软的office办公迁移到google的在线办公上面去;把outlook的email发信收信功能迁移到hotmail上面去了。换句话说，WEB应用程序必定会带来一系列的安全问题。如今的WEB安全早已经成为了焦点。当然，也成了开发者和黑客们之间战场!根据OWASP统计，大部分WEB应用程序都是不安全的，有些甚至都没有接触过SSL这个东西。去年OWASP发布了一个跟web有关的漏洞分布图，见下：
自己去琢磨参透一下上图的含义吧。
三、 核心防御机制
核心的防御元素概况起来有这么几点：(1)处理用户的每个访问点，确保用户不会获得没有授权的存取这是每个WEB应用都应该做到的安全点位，目的是控制和处理用户的每个授权点。不同的用户都有自己不同的访问区域，比如匿名用户，普通用户，管理员，他们都能访问到属于各自不同权限范围内的内容。如果要细分一下，不如看看之前有牛人提到的纵横的权限授权注意事项。这里提出3个重要的，影响防御机制的要素：::1 认证环节，WEB访问用户是谁?匿名用户还是普通用户，还是管理员?::2 会话管理，每个会话ID都精确对应到访问的每个访问用户，如何控制和处理好它们?::3 访问控制，对每个单独的请求都要做出正确的存取判断，到的是允许还是拒绝?
以上3个核心环节，缺一不可，就好比一个连锁酒店一样，任何一个环节出了问题都可能导致黑客可以绕过其安全机制获得非法访问的权限。(2)处理用户每次输入，阻止不希望看到的输入形式出现众所周知，黑客每次都输入各种稀奇古怪的字符来攻击WEB应用。对此，采取对输入的数据进行校验是WEB安全防御中最大的一个安全防护环节。不可轻视。 (3) 应对攻击者，采取适当的防御性甚至主动防御性的措施来挫败攻击者这关键还是看WEB应用程序的安全防御机制。上面提到防御性措施和主动性防御旨在阻挠黑客进一步渗透和攻击系统。这期间，如果能将被攻击的消息和数据发送给网站管理员的话，将有助于及时封堵网站的安全漏洞。我来举个例吧，比如有个黑客通过一句话木马老去链接一个网站的一个文件。1个小时下来，这个文件的访问频率肯定是非常高了。剩下的，你懂的。类似的，针对攻击者的安全防御机制还有： 错误信息处理，日志审核，重复攻击，管理员监控警报等等。(4) 应用程序管理，类似自检功能。管理员需要将程序的功能都监控起来(比如日志记录)，听起来有点像QA做的事情。目的是要确保这个功能接口的配置正确。(不正确的WEB应用程序配置，常常是开发者带给黑客的“礼物”，这不是运维的问题，不要混淆，这里没有在搭建配置NGINX)。纵观一下，大部分WEB应用程序都有一个类似管理后台，而大部分管理后台中却有安全机制不太明确的地方。我注意到有这么几个内部安全弱点: ::1 在认证环节，如何判断对方是否是真正的管理员。一个攻击者通过类似万能密码就进入了管理后台，这很有可能危及整个WEB主机安全。 ::2 有的管理面板在后台可以创建一个跟管理员权限一样大的用户出来，这种高级权限的分发机制有时候很难把控。 ::3 跨站攻击能够让一个具有管理员权限的session会话暴露给其他非法的使用者，还记得打后台的那些xss脚本吗?在应用功能模块里对边界层数据进行校验是不可缺少的：
四、攻击应用
第一步得做的，自然是尽可能多的收集需要攻击站点的信息。下面列出的步骤可以方便您在“攻击”之旅上更顺畅：
(1) 像蜘蛛一样收集对方站点信息当然目标是全面的收集有用的站点内容信息。想要最快的熟悉查看对方的网站布局，可以看看robot.txt 和 对方的网站地图。有时候在这些文件里常常隐含着一些敏感的信息，您一定会对其感兴趣的。而这样的信息收集工具都有哪些呢，举例如下：- Paros 这是一个java程序，基于http和https的方式来评估web的安全风险，可以在线编辑提交给服务器端的http消息体(有点像burp和zap)。其他特性包括蜘蛛功能，客户端证书，代理链，集成的xss和sql注入扫描功能。- Burp Spider 这个不多说了，玩过burp都知道，更的介绍来这里看看。- Web Scarab 这个工具是一个可以分析http/https协议的框架工具，也是java写的，跨多平台。有多种工作模式，含有大量插件，用法都较为常见，易学上手。当用蜘蛛收集这些站点的信息的时候，我们总是希望可以得到一些隐藏的内容比如备份文件和一些有用的文档。比如，我们如果可以通过蜘蛛爬行获得一些对方网站新开发的功能模块(这些模块页面由于没有测试而匆忙上线的)，或者得到一些没有下线的有漏洞的老网页模块，一些有价值的配置文件等等(包含文件，源文件和日志文件等等)。
(2)投射攻击面把您采集得到的信息投射到不同的攻击层面上来和攻击渠道结合起来看的话，我们大致列出下面的几个方面供大家参考：
- 客户端校验 有些WEB代码在客户端校验用户的数据，尝试检查一下这些数据是否在服务器端有无做过校验?
- 数据库交互 注意检查是否有sql注入攻击
- 文件的上传和下载 注意检查是否有LFI漏洞和#0覆盖漏洞
- 用户输入数据展现 是否可以考虑可以丢个跨站脚本上去
- 动态的网站重定向 是否可以注入恶意的http header进去
- 用户登录 此处可以枚举用户，弱口令用户和暴力破解用户密码?
- 多级登录 对方的登录逻辑是否完善可靠,比如oauth 1.0
- Session数据 考虑对方是否正确的处理了Session数据,其数据令牌是否可以被猜解?
- 权限控制 对方是否对垂直和水平权限深刻领悟?有些开发者者真的就是只懂编码，真正的码农，可悲。
- 用户模拟 尝试修改URL参数来提升登陆用户的访问级别，特权访问- 明文通讯 session劫持，捕获用户登陆凭证和敏感数据
- 离线的站点链接 有些高端网站用了url重写隐藏了真实地址上面的参数，离线站点链接可能暴露了这些参数的真实排布
- 系统对外的开放的接口 这些接口往往泄露了一些特别的存取权限和特定session的处理接口- 错误消息 一些敏感信息泄露(类似http 500 错误泄露的mssql信息)
- 电子邮件交互 是否可以邮件挂马发给对方使其中招?
- 本地代码组件下载 此类组件往往跟服务器有通讯接口，该接口是否可以溢出?
- 第三方组件 众所周知的漏洞利用，比如大牛最爱的fckeditor…- web标头信息的泄露 该信息可以明确对方的web服务器版本，跑的什么服务，这些版本和服务都有什么众所周知的漏洞可以加以利用。
(3)关于绕过客户端机制的举例- 表单里面的隐藏域看看下面这段代码：
Product: Sony VAIO A217S
Quantity:
很明显，price就是一个隐藏域，它会被POST提交：POST /order.asp HTTP/1.1
Host: wahh-app.com
Content-Length: 23
Quantity=1&price=1224.95
我们可以采用2种方式来修改隐藏域，1、将它们保存到本地,然后用html代码填写好相应的价格，提交到服务器。2、用上面我们提到的交互式工具webscrab或者burp来实时修改提交的参数。这样就能随意的修改这个价格参数了(如果服务器端不做校验的话)。http cookies如何修改cookies呢?作为提交数据的一部分，我们可以用交互式的webscrab或者burp来实现。当然了，现在也有人玩fiddler，工具是死的，人是活的。绕过客户端数据检查的相关的方式还有很多，比如url参数变化，referer的改写等等。结论WEB服务器端接受客户端提交的数据最终不像预期那样可信。在客户端对数据进行的校验，最终都可能在提交的过程中被修改。具备简单的工具和很少的技术含量就可以实施客户端的攻击。我们应该规避这些攻击，而且也是可以做到规避的。就看你做没做。
五、攻击认证机制
这个比较好玩，认证最好的体现就在登陆用户上面。首先我们要做的就是看看这个网站是否有对注册密码的严格要求。如果一个网站没有对密码的严格规定，那么必定存在弱口令密码之类的东西。如果对方没有对密码认证制定严格的策略的话，那就可以使用暴力破解的工具来对弱口令账号进行攻击。其他攻击认证机制的环节有：1. 拦截数据包，并且修改数据包 如果对方在处理认证凭证上面不是太下功夫的话2. 密码更改功能 是否可以改到其他账号的密码3. 密码找回功能 还记得用burp找回账号丢失的密码吗?4. “记住我”这个按钮的功能使session持久，以至于可以持久到被人xss后还可以用。5. 后台可以预见的初始化密码， 比如 admin888 地球人都知道的6. 不安全的证书分布 遗失的SSL证书验证机制可能让后台形同虚设7. 不安全的存储凭证 有些安全凭证被存放到了可以被非法获取的地方最重要的实践还是要从不同的角度去尝试。特别留意主窗口的登陆窗体，那里常常有注册账号，找回密码，记住密码等诸多功能。这些地方都富含了潜在的漏洞和缺陷。花时间到攻击映射层面的每个地方，也许真的会换来意想不到到的“回报”。
