坐拥IT高薪安全工程师职位必备知识——web前端黑客与渗透测试基础

本日志对《黑客攻防技术实战宝典：web应用程序篇》，《白帽子讲web安全》等书进行知识总结与提炼，欢迎广大读者交流心得

常见web应用程序采用的核心防御机制（攻击互联网上实际的web应用程序时要从这些角度考虑可行性，才不至于遗漏任何方案，并且尽可能绕过检测）

首先确定一个web应用程序的类型：
类型 （典型应用代表）

购物（Amazon）
社交网络（Facebook）
web搜索（Google）
银行服务（Citibank）
拍卖（eBay）
博客（blog / Blogger）
web邮件（Gmail）
交互信息（wikipedia）
博彩与投机（Betfair）

其他的一些大型复杂web应用，其架构由具备上列功能的一种或者多种web组件构成

核心防御机制

处理用户访问：
身份验证
会话管理
访问控制

处理用户输入：
基于黑名单过滤
基于白名单过滤
基于对输入进行编码，转义等的净化
基于web应用组件边界过滤（考虑面对综合部署多种防注入程序或逻辑的web应用）
web应用程序及其所有构成组件应部署检查“所有类型的用户输入”的程序来实
行边界确认，具体而言：
1。采用表单处理程序的输入确认机制，检查用户在登录阶段潜在的恶意输入；
2。采用SQL防注程序或代码，检查已登录用户执行涉及数据库操作的恶意输入；
3。采用HTML编码来防御可能造成跨站脚本的恶意输入
（XSS过滤步骤应放在URL解码之后，以防止攻击者采用多重嵌套的URL编码，逃避检测）；

处理攻击者：
处理错误 ：正确处理并且屏蔽返回包含关键系统或web应用信息的错误页面

维护审计日志：其中包含攻击者能假冒的任何已验证用户的登录信息，会话令牌，请求参数
在服务器本地磁盘上的web应用程序审计日志应妥善（隐秘）存放并设
置密码以及访问权限，
甚至禁止通过内网访问，或者将其移动至“移动存储介质”，必要时，
用非连入网络的单机保存和维护

向管理员发出警报：提供攻击者的IP信息便于锁定。发出警报的判定标准：
1。短期内源自特定IP的大量请求流量；
2。金融业务类web应用程序（如网络银行）中特定账户的转入
及转出资金数量异常；
3。普通用户无法查看或修改的请求数据被更改；
4。请求或者查询中包含任何标准（或公认的）攻击字符串注
入；
5。自定义的警报标准（取决于web应用的安全功能是否支持）
甚至包含：
cookie中特定参数被修改，
利用浏览器代理工具修改HTTP请求或隐藏表单字段时，
都有被检测出的风险；

应对攻击：自动化的防御措施，不需要人工干预，如自动锁IP，终止会话，自动重定向等；

管理应用程序 ：web应用程序的管理员登录页面（常应用于论坛，博客等整站程序的后台）的验证机制薄弱且存在漏
洞，导致（黑客）可以获取webshell甚至cmdshell，找出管理后台的地址就是关键所在；

blog（博客）为一种类型的web应用程序。当博客用户发表文章或者评论他人文章时，按下的相应按钮（以开发者角度称为“控件”），实际上是由web浏览器将这些用户输入通过HTTP请求或者其他形式提交给服务器端。
如果服务器端的web应用程序不执行任何用户输入检查（验证），就将这些字符串存储在后台数据库甚至硬盘上，并且向其他用户显示，很容易造成“存储型跨站脚本漏洞”。
换句话说，当其他用户的web浏览器访问一个被注入恶意HTML代码并存储显示的页面时，这些有漏洞的浏览器会执行其中的恶意 JavaScript脚本部分，造成：
1。访问非预期的第三方挂马站点（术语“XSS跨站脚本”由此而生）；
2。用户 HTTP cookie 中的会话令牌泄漏 ；
3。通过漏洞浏览器在受害用户机器上执行其他危险的系统命令等；

会话：：一组保存在服务器上的数据结构，记录特定用户与应用程序的交互状态（可视为用户权限）。不同的用户有不同的会话，常对应着执行web应用程序的不同用户权限。

会话令牌（Session Token）：：建立会话时（包括通过验证的登录用户以及未验证的匿名用户），由web应用程序发给客户端用户的 一个唯一标识该会话（用户权限）的字符串。web浏览器将在随后的HTTP请求中携带，便于web应用程序赋予其相 应的用户权限
（黑客）通过推测，假冒以及劫持任何已验证（登录）用户的会话令牌，就可以在不知道该用户账户与密码的情况下，以相等权限访问应用程序。
这个漏洞是由于令牌仅与会话本身相关联，而不与账户密码相关联的设计缺陷导致的。

会话令牌的双重危险：
1。会话令牌被假冒，即可以合法用户的权限；来访问 web 应用程序
2。不同的 web 服务器以及 web 应用程序平台，使用不同前缀的会话令牌名称，可用以识别目标站点采用
的相关技术，例如：
JSESSIONID（Java 平台）；ASPSESSIONID（Microsoft IIS web 服务器）；
ASP.NET_sessionId（Microsoft ASP.NET）；
CFID / CFTOKEN（cold fusion）；PHPSESSID（PHP）。
这是最准确有效识别目标服务器采用的开发技术的办法，即使目标返回错误的页面被自定义，或者采
用其他手段来隐藏相关的信息。

隐藏表单字段，URL 查询字符串，以及HTTP cookie 是常见的三个传送会话令牌的区域。这些区域的内容可以使用 burp Intruder 或者其他浏览器代理软件来查看，修改。

HTTP（超文本传输协议）是运作在应用层（以TCP / IP 模型为参考）上的协议。它使用其下一层（传输层）的TCP协议作为传输机制。
同时它为许多运作在应用层之上的web应用程序提供底层通信协议（换言之，web应用程序使用HTTP提供的服务；而HTTP又使用TCP协议提供的服务；最后，TCP协议使用更底层【网络层】的IP协议提供的服务）
虽然HTTP本身是无连接状态的协议，但它基于的TCP协议则需要连接。
默认状态下，每次访问服务器都需建立包含3次”握手“的TCP连接。有鉴于此，HTTP请求的 connection 消息头可以用以控制每次在服务器发送HTTP响应后是保持TCP连接还是断开：
当 connection 的值为 keep-alive 时，告诉服务器在发送响应后继续保持连接。在某些情况下可避免通信双方因重新建立连接过程带来的时间开销

常见的HTTP请求消息头（字段）

If-Modified-Since：
当同一个用户在不同时间请求相资源时，客户端（通常是web浏览器）在HTTP请求中
携带该请求头，用以向服务端（通常是web服务器）说明：最近一次收到的上个相同
资源的时间。
服务端将该时间（If-Modified-Since的值）的资源状态与服务器当前系统时间的资
源状态作比较；
如果资源没有更新，则服务器在随后的HTTP响应将第一行第2项的数字状态码置为
304，并且响应体为空，表明要客户端直接读取保存在本地缓存的资源副本。
如果资源在这段时间已更新，则服务端会在响应体中包含相应的更新资源。这样不但
可以提升其它用户端访问web站点的效率，速度；同时也减轻服务器处理与传输大量
相同资源的负荷 。

Referer：
该单词在最初的HTTP规范中存在拼写错误，并且该错误单词一直（刻意）沿用至今。
表示发出本次请求的宿主页面对应的URL。例如用户因为单击某页面的超链接，则产生的HTTP请求第
一行第2项就是包含目标资源的URL（不含HOST值的非完整URL）
Referer 的值就是超链接所在（宿主）页面的完整URL。

user-Agent：
该请求头包含与浏览器或生成本次请求的其它客户端软件种类，版本有关的信息。
由于Mozilla 的 Netscape 浏览器是在万维网发展早期阶段占主导地位的web浏览器，且首次
使用该字段 ；
当时的其它浏览器厂商为了让web站点与用户相信其产品与Mozilla的标准兼容，均使用带 Mozilla值的 user-Agent 消息头。
这个不成文规矩（或历史原因）延续到现在，导致多数浏览器生成的HTTP请求都带有Mozilla
值的 user-Agent消息头。

常见的HTTP响应消息头（字段）

Expires：
用于标识响应主体内容（资源）的有效时间。在这个时间之前，浏览器可以使用该资源在本地缓存
的副本；
如果响应中的 Date 消息头（即服务器上的系统时间）晚于 Expires的值，可能表示该资源已有更
新版本：
服务器会将响应消息头中的 Cache-control 与 Pragma 消息头的值置为 no-cache ，指示浏览器
不要读取本地缓存中的旧版资源，并在响应体中发送新版资源。

Location：
当响应第一行第2项的状态码为3xx 时，该消息头可能包含：将之前的客户端请求重定向至何处的
信息。
具体而言，当状态码为 301 Moved Permanently 时，将浏览器永久重定向至 Location字段指示
的URL。
当状态码为 302 Found 时，仅将本次浏览器的请求URL重定向至 Location字段指示的URL；但在
后续的客户端请求中不会重定向。

set-cookies：
将该 cookies 的值发送给客户端，客服端在随后的请求中的 cookies 消息头中携带同样的
值，服务端根据该值来为每个客户端提供个性化以及自定义的web页面元素，功能设置，或其
它隐私的信息等。

www-Authenticate：
若服务器要求进行HTTP内置身份验证，
或之前客户端请求中的 Authorization 消息头的值与服务器所支持的内置HTTP身
份验证的证书类型不符，则服务器将响应第一行第2项的状态码置为401，表示之前
的请求错误，同时将该消息头的值置为服务器支持的内置HTTP身份验证类型，用以
告诉客户端重新发送包含正确证书类型的请求。

cookie 是HTTP协议的组成部分，通常与多数采用HTTP协议的web应用程序安全密切相关，其特点有：
1。服务器采用 set-cookie 消息头在响应中发布 cookie，cookie一般由 “名 / 值对” 构成，注
意其不包含任何空字符；也可仅由不含空字符的字符串组成；
2。多数情况中，客户端自动在每次请求的 cookie 消息头中携带，而请求方法，请求体，请求的部
分URL等参数则需由用户或应用程序指定；
3。服务器可在响应中使用多个 set-cookie 字段发布多个 cookie ；客户端可在请求中用一
个 cookie字段携带所有 cookie，但不同 cookie 之间需用分号隔开；
4。只有服务器发布的 set-cookie 字段可设置除 cookie 值本身外的其它参数，用以控制或限
定 cookie 的属性与浏览器处理它们的方式；
expires：
指定了 cookie 的有效时间。浏览器在本地磁盘中保
存 cookie ，意味着可重复使用 cookie，直到有效日为止。
当不含 expires 参数时，该 cookie 为一次性使用，即不会
保存在本地磁盘，而且仅在当前浏览器与服务器的会话中有
效，重新建立会话即失效（例如重启浏览器进程等）

domain：
指定 cookie 的有效域。设置该参数后，即便位于有效域外的
攻击者劫持到 cookie ，也无法加以利用。

path：
指定 cookie 的有效URL路径。该 cookie 在站点的其它URL中使用
无效。

secure：
设置该参数表示仅允许客户端在HTTPS请求中提交 cookie。

HttpOnly：
设置该参数表示禁止通过客户端 JavaScript 脚本代码直
接访问 cookie。

【常用状态码详解】

每条HTTP响应消息都必须在第一行第2项中包含特定状态码，说明上一个请求的结果。攻击web应用程序或进行渗透测试前，需对下列常遇到的状态码有明确的理解。

201 Created ：
使用 put 方法的请求成功时，随后的响应返回该状态码，通常意味着上传文件成功。

301 Moved Permanently ：
表示将上个请求重定向至响应的 location 消息头指定的URL中，并且
往后的请求均会访问新的URL（永久重定向）

302 Found ：
表示仅将上个请求重定向至响应的 location 消息头指定的URL中，并且往后的请求不会被重
定向（暂时重定向）

304 Not Modified ：
指示浏览器应使用本地缓存中的资源副本，因为服务器上的相同资源还未更新。

400 Bad Request ：
表示客户端提交了一个无效的HTTP请求（通常是通过浏览器地址栏，或其它方式修
改了请求URL的原因，例如插入空字符，或在结尾加上类似撇号，连字符等攻击字
符串来尝试SQL注入）

401 Unauthorized ：
服务器要求进行HTTP身份验证，它会在响应的 www-Authenticate 消息头中指出其
支持那种验证类型。客户端应重新按要求发送验证请求。

403 Forbidden ：
不管是否通过身份验证，一律禁止访问被请求的资源。

404 Not Found：
被请求的资源不存在。

405 Method Not Allow ：
所请求的URL不支持请求使用的方法。例如请求禁止 put 方法的URL则会返
回该状态码。

413 Request Entity Too Large ：
表示请求体的内容过长，无法处理（通常意味着目标站点存
在某种缓冲区溢出漏洞，但已被修补或者屏蔽）

414 Request URI Too Large ：
表示请求的URL过长，无法处理。

500 Internal Server Error ：
表示服务器处理请求时遇到错误，并且web应用程序无法继续处理该
请求。此时应检查该响应的其余部分来了解错误原因。

503 Service Unavailable :
表示web服务器暂时无法或没空响应本次请求，或者服务器忙碌，或者
正在维护，或者到本地的物理线路通信问题等。

◆下面是常见的 web 应用程序具备的功能与对应可能存在的漏洞列表。对于互联网上的各种网站执行基于此模版的安全审计，可以快速，全面，准确定位目标站点的漏洞。
典型 web 应用程序功能 该功能对应的可能漏洞列表 （目标站点的 web 应用程序是否具备该功能）
（尝试对目标站点发起相应的攻击）

客户端确认功能 可能存在服务器没有采用确认检查的漏洞

数据库交互功能 可能存在各种SQL注入漏洞

文件上传与下载功能 可能存在路径遍历漏洞，存储型跨站脚本漏洞

显示用户提交的数据的功能（如论坛） 可能存在跨站脚本漏洞

动态重定向功能 尝试执行重定向与消息头注入攻击

社交网络功能 尝试执行用户名枚举攻击；可能存在存储型跨站脚本漏洞

登录功能 尝试执行用户名枚举攻击或者蛮力攻击
（基于暴力破解或者字典文件，彩虹表破解）；可能存在弱口令漏洞

多阶段登录功能。 可能存在对应的登录（逻辑）漏洞

会话状态功能。 尝试进行推测会话令牌的攻击

访问控制功能。 尝试横向与纵向提权

用户伪装功能。 尝试提权

使用明文通信（漏洞）。 尝试会会话劫持，收集证书与其它敏感数据

站外链接（友情链接）功能。 尝试 HTTP Referer 字段注入攻击

显示错误页面功能。 可能存在信息泄漏（web 服务器类型版本，开发语言平台，数据库类型等）

本地（目标机器上的）编译型组件（如 DLL 动态链接库）功能。 尝试相应的缓冲区溢出攻击
使用第三方开源或商业的现成 web 应用程
序组件，模块，对第三方组件已知的漏洞进行
相应攻击

电子邮件交互功能。 尝试电子邮件命令注入攻击

【注入攻击基础】

◆由于多数 web 应用程序的输入确认机制及放注入组件会过滤掉危险字符（仅字面值），所以攻击者将这些字符（字面值）以各种形式编码，尝试逃避检测，从而达到执行危险的数据库操作目的。
例如，假设 web 应用程序过滤空格字符，%，？，&，=，+，-，# 等字符的字面值形式，但允许这些字面值对应的 URL 编码形式，那么就可以将其先进行 URL 编码后再输入：：
将 = 编码为 ％3d ；将 ％ 编码为 ％25；将空字符编码为 ％00；将空格字符编码为％20 等等。
任何以 URL 编码的字符都以 ％ 开头，且后面跟着该字符的两位16进制 ASCII 码。注意这里为清晰显示的缘故，使用了 unicode 形式的 ％，实际上，该字符是 ASCII 格式的，即 %。上列其它特殊字符也是如此。
另一种常用的编码技术为 UTF-8 编码。它用多个字节来编码一个“unicode 字符字面值”。每个字节以 % 开头，且后面跟着两位16进制数。例如：
将 unicode 字符字面值 ≠ 进行 UTF-8 编码后为 %e2%89%a0。
该编码技术同样可用于浏览器地址栏，或者任何拦截代理服务器的 HTTP 请求 URL注入攻击，以绕过各种检测机制。

◆再次强调，有些防注入程序会过滤掉攻击者在浏览器地址栏以字面值形式输入的特殊字符，这时就可以首先了解各种危险字符字面值的对应 URL 编码或者 UTF-8 编码形式，然后以这些编码后的形式进行输入注入攻击即可。（可以使用 burp suite web渗透测试套件 的 decoder 模块）

◆一些 web 应用程序采用主动式的 HTML 编码来防止构成跨站脚本的危险字符字面值输入，并将 HTML编码后的结果显示在 HTML 页面文档中。
例如将危险字符字面值 < 采用 HTML编码成 <； > 采用 HTML 编码成 >； ' （单引号）编码成 &apvs； " （双引号）编码成 "；
如果一个 web 应用程序的 HTTP响应中没有对之前客户端发送的 HTTP请求首部或者请求主体中的数据进行 HTML编码，可能意味其存在跨站脚本漏洞。

◆Base64 编码技术采用 ”仅能打印的ASCII字符集” 来编码（用户输入的）数据。其特征是：编码后的数据长度（字符串）应为64个可打印的ASCII字符。或者以一个或两个“补足字符”（=）结尾的字符串（当源数据长度不足以编码成64位时）
此外，许多 web 应用程序将 cookie 的值以 Base64 编码形式加密。通过上述两个特征即很容易判断是否采用 Base64 编码，并且使用相应的解码工具破解。（可以使用 burp suite web渗透测试套件 的 decoder 模块）

【客户端控件与浏览器扩展专题】

客户端控件是指：在分布式架构的 web 应用程序中的客户端部分。 web 站点中常见的客户端控件有：

轻量级客户端控件：HTTP 表单（包括其中的隐藏字段）；客户端脚本如 Javascript ；
什么是浏览器扩展？
在浏览器提供的沙盒执行环境中（如虚拟机）运行的客户端控件：一般情况下简称为浏览器扩展。

和客户端相关的其它（用于攻击渗透测试的）输入点（这些输入点可用 burp suite 操纵）：
◆HTML 页面源代码的隐藏表单字段（input type = "hidden"）；禁用元素字段（disabled = "ture"） 只需查找 HTML页面源代码的相应字符串来定位，并且使用 burp suite 来查看，修改隐藏表单字段与重新启用元 素。

◆HTTP cookie：重点在用 burp suite 修改服务器响应发布的 set-cookie 字段值，并在随后的请求中发送修改后 的值。URL 参数，如查询字符串：通常可在浏览器地址栏中直接修改，但在 burp suite 中修改更直观方便。另外，对于一些使用“表述性状态转移”与将查询字符串转换成静态结果安全显示在浏览器地址栏的 web 应用程序，以burp 的代理来修改会更有效。

◆Referer 消息头：这个HTTP 请求首部字段值同样可以在 burp 中修改，
效果是欺骗某些信任此字段（以此字段为判断依据）的 web 应用程序。

◆加密的或模糊的数据：位于 HTML 页面源代码或 HTTP 响应体中，同样可用 burp decoder 模块查看，修改并重新 发送。这里的重点在于，应了解特定加密或者编码数据的加密算法 / 编码，以相应的解码器还原出明文。或者将 恶意的明文以同样的算法 / 编码 加密后替换原始数据，再行发送。 强调一点：若直接修改已加密的原始数据散列值发送，会导致数据被破坏性修改，使服务器或者 web 应用程序无
法还原明文，导致攻击失败。
参考专题：一种加密 / 模糊数据 的实现—— ASP.NET viewState

◆对于用以检查用户输入数据的嵌入 HTML 页面源代码的轻量级 Javascript 脚本（以 <script> 标签开头）， 有时只需设置浏览器禁用 Javascript 即可绕过该控件，或者用 burp 删除 / 修改 Javascript 中执行安全验 证的代码部分，再行发送即可。

仅使用在客户端的控件检查用户输入会造成何种安全隐患？
攻击者可以利用控件的漏洞或者采用各种方式绕过控件。对于后者，如果在服务器端没有部署额外的输入检
查，则 web 应用程序的服务端部分“会以不安全的行为”来处理这些输入的数据，从而达到攻击者的目
的。

即使客户端控件执行的安全检查机制能被绕过，但仍需部署客户端控件的原因
提高用户访问 / 登录站点时的速度体验。（对于合法输入字符而言）减少输入数据在服务端进行检查，并
回传客户端的时间开销。
如果不采用客户端控件，检查并通知客户端更正一个非法输入的字符需要重复向服务器发送请求进行检查，
再次加载相同页面供用户输入。这不仅增加多余的数据来回传输时间，也增加服务器的负担（假设服务器需
在本机给每位用户进行检查）。

常见的浏览器扩展技术与对应的序列化数据（格式）
攻击浏览器扩展的方法
◆使用 burp 拦截浏览器扩展产生的序列化数据流量，解码，修改，重新编码后发送。◆对浏览器扩展本身（字节码）进行反编译或者动态调试，探查并将源代码修改成有漏洞的版本后重新编译并加载执 行。从而通过漏洞版本的控件对服务器进行输入注入攻击。参考《反编译浏览器扩展字节码文件的具体流程》

本文出自 “自由，平等，共享，互助” 博客，请务必保留此出处http://shayi1983.blog.51cto.com/4681835/1399997