【信息安全原理】——Web应用安全（学习笔记）

📖 前言：Web是互联网上最为典型的应用模式，几乎涉及人们生活的各个方面，因此其安全问题备受关注。本章我们首先聚焦Web应用本身的安全问题，包括：Web应用体系的脆弱性分析，典型Web应用安全漏洞攻击（SQL注入、XSS、Cookie欺骗、CSRF、目录遍历、操作系统命令注入、HTTP消息头注入等）及其防范措施，然后简要介绍安全的HTTP协议HTTPS。

---

目录

• [🕒 1. Web应用体系结构脆弱性分析](#🕒 1. Web应用体系结构脆弱性分析)
• • [🕘 1.1 Web应用安全](#🕘 1.1 Web应用安全)
  • [🕘 1.2 HTTP协议安全问题](#🕘 1.2 HTTP协议安全问题)
  • [🕘 1.3 Cookie的安全问题](#🕘 1.3 Cookie的安全问题)
• [🕒 2. 常见Web应用攻击及防范](#🕒 2. 常见Web应用攻击及防范)
• • [🕘 2.1 SQL注入攻击及防范](#🕘 2.1 SQL注入攻击及防范)
  • • [🕤 2.1.1 SQL注入原理](#🕤 2.1.1 SQL注入原理)
    • [🕤 2.1.2 SQL注入攻击流程](#🕤 2.1.2 SQL注入攻击流程)
    • [🕤 2.1.3 SQL注入检测](#🕤 2.1.3 SQL注入检测)
    • [🕤 2.1.4 实验：SQL注入](#🕤 2.1.4 实验：SQL注入)
  • [🕘 2.2 跨站脚本（XSS）攻击及防范](#🕘 2.2 跨站脚本（XSS）攻击及防范)
  • • [🕤 2.2.1 工作原理](#🕤 2.2.1 工作原理)
    • [🕤 2.2.2 反射式XSS](#🕤 2.2.2 反射式XSS)
    • [🕤 2.2.3 储存式XSS](#🕤 2.2.3 储存式XSS)
    • [🕤 2.2.4 DOM式XSS](#🕤 2.2.4 DOM式XSS)
    • [🕤 2.2.5 防御XSS](#🕤 2.2.5 防御XSS)
    • [🕤 2.2.6 实验：XSS攻击](#🕤 2.2.6 实验：XSS攻击)
  • [🕘 2.3 Cookie欺骗及防范](#🕘 2.3 Cookie欺骗及防范)
  • • [🕤 2.3.1 伪造Cookie信息](#🕤 2.3.1 伪造Cookie信息)
    • [🕤 2.3.2 监听Cookie来实现会话劫持](#🕤 2.3.2 监听Cookie来实现会话劫持)
  • [🕘 2.4 CSRF攻击及防范](#🕘 2.4 CSRF攻击及防范)
  • [🕘 2.5 目录遍历及其防范](#🕘 2.5 目录遍历及其防范)
  • [🕘 2.6 操作系统命令注入及防范](#🕘 2.6 操作系统命令注入及防范)
  • [🕘 2.7 HTTP消息头注入攻击及防范](#🕘 2.7 HTTP消息头注入攻击及防范)
  • [🕘 2.8 其他攻击](#🕘 2.8 其他攻击)
  • • [🕤 2.8.1 恶意文件执行](#🕤 2.8.1 恶意文件执行)
    • [🕤 2.8.2 不安全的直接对象引用](#🕤 2.8.2 不安全的直接对象引用)
    • [🕤 2.8.3 信息泄露和不当的错误处理](#🕤 2.8.3 信息泄露和不当的错误处理)
    • [🕤 2.8.4 认证和会话管理不完善](#🕤 2.8.4 认证和会话管理不完善)
    • [🕤 2.8.5 不安全的加密存储](#🕤 2.8.5 不安全的加密存储)
    • [🕤 2.8.6 URL访问缺少限制](#🕤 2.8.6 URL访问缺少限制)
• [🕒 3. HTTPS](#🕒 3. HTTPS)
• • [🕘 3.1 提出背景：不安全的通信](#🕘 3.1 提出背景：不安全的通信)
  • [🕘 3.2 防御](#🕘 3.2 防御)

🕒 1. Web应用体系结构脆弱性分析

Web应用体系结构潜在弱点：

• Web客户端
  • 活动内容执行，客户端软件漏洞的利用，交互站点脚本的错误
• 传输
  • 偷听客户-服务器通信，SSL重定向
• Web服务器
  • Web服务器软件漏洞；
• Web应用程序
  • 攻击授权、认证、站点结构、输入验证，以及应用程序逻辑
• 数据库
  • 通过数据库查询运行优先权命令，查询操纵返回额外的数据集。

🕘 1.1 Web应用安全

Web应用程序功能与安全隐患的对应关系

🕘 1.2 HTTP协议安全问题

HTTP协议是一种简单的、无状态的应用层协议（RFC1945、RFC2616）

• 无状态使攻击变得容易
• 基于ASCII码，无需弄清复杂的二进制编码机制，攻击者就可了解协议中的明文信息
• 互联网中存在的大量中间盒子，HTTP标准(RFC 2616和RFC 7320)的理解如果不一致，就有可能导致一些新的攻击发生

常见安全问题：

• HTTP会话经常被劫持
  

• HTTP会话头泄露隐私信息
  

• 中间盒子带来的HTTP安全问题

🔎 端到端通信中危险的中间盒子：祝福还是诅咒？

🕘 1.3 Cookie的安全问题

为什么需要Cookie？

• 解决无状态问题：保存客户服务器之间的一些状态信息
• Cookie是指网站为了辨别用户身份、进行会话跟踪而储存在用户本地终端上的一些数据（通常经过编码），最早由网景公司的Lou Montulli在1993年3月发明的，后被采纳为RFC标准（RFC2109、RFC2965）

Cookie的生成与维护：

• 由服务器端生成，发送给客户端（一般是浏览器），浏览器会将Cookie的值保存到某个目录下的文本文件内，下次请求同一网站时就发送该Cookie给服务器（前提是浏览器设置为启用Cookie）
• 服务器可以利用Cookie存储信息并经常性地维护这些信息，从而判断在HTTP传输中的状态
• Cookie在生成时就会被指定一个Expire值，这就是Cookie的生存周期。到期自动清除
• 如果一台计算机上安装了多个浏览器，每个浏览器都会在各自独立的空间存放Cookie
• Cookie中的内容大多数经过了编码处理

Cookie的一般格式如下：
NAME= VALUE; expires= DATE; path= PATH;
domain= DOMAIN_NAME; secure

示例
autolog = bWlrzTpteXMxy3IzdA%3D%3D;
expires=Sat, 01-Jan-2018 00:00:00 GMT; path=/;
domain=victim.com

Cookie中包含了一些敏感信息，如用户名、计算机名、使用的浏览器和曾经访问的网站等，攻击者可以利用它来进行窃密和欺骗攻击

🕒 2. 常见Web应用攻击及防范

OWASP（开放式Web应用程序安全项目）是一个开放的社区，由非营利组织 OWASP基金会支持的项目。对所有致力于改进应用程序安全的人士开放，旨在提高对应用程序安全性的认识。

其最具权威的就是"10项最严重的Web 应用程序安全风险列表" ，总结并更新Web应用程序中最可能、最常见、最危险的十大漏洞，是开发、测试、服务、咨询人员应知应会的知识。

🕘 2.1 SQL注入攻击及防范

定义：注入漏洞，特别是SQL注入，在Web应用程序中很常见。注入发生在用户提供的数据作为命令或查询的一部分发送到解释器时。攻击者的恶意数据欺骗解释器执行意外的命令或更改数据。

最普遍的注入漏洞包括：

• SQL注入：通过SQL语句恶意地调用后台数据库
• 系统调用
• 通过shell命令调用外部程序

🕤 2.1.1 SQL注入原理

例子：

• 通过用户提供的参数来查询表中的数据
• "SELECT * FROM USERS WHERE SSN='" + ssn + "'"

SSN参数来自于用户的输入：

• 参数未经验证或编码
• 黑客输入： 1234' OR '1'='1

应用程序构造查询语句：

• SELECT * FROM USERS WHERE SSN='1234' OR '1'='1' （永真逻辑）
• 结果返回数据库中的每一个用户

🕤 2.1.2 SQL注入攻击流程

1. Web程序提供了用户输入的表单；
2. 攻击者通过填写表单数据发起攻击；
3. Web程序通过SQL语句的形式将攻击递交给数据库；
4. 数据库执行SQL语句，将执行结果加密后返回给应用程序；
5. 应用程序解密数据，将结果发送给用户（攻击者）。

说明：SSL、防火墙等安全措施对于此类攻击完全没用。

实战：🔎 IBM所提供的Web安全漏洞演示网站

1. Web应用有一个登录页面，这个登录页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码，登录页面中输入的内容将直接用来构造动态的SQL命令 或者直接用作存储过程的参数

System.Text.StringBuilder.query = new System.Text.String.Builder（"SELECT * from Users WHERE login =").Append（txtLogin Text).Append（"'AND password="').Append（txtPassword.Text).Append（""）

2. 攻击者在用户名字和密码输入框中输入 'or'1'='1 的内容
3. 服务器运行上面的ASP NET代码构造出查询用户的SQL命令，最后得到的SQL命令变成

SELECT * from Users WHERE login = 'or '1'='1'  AND  password 'or '1'='1'

🕤 2.1.3 SQL注入检测

🔎 DVWA靶场------下载与安装

🔎 sqlmap详细使用教程

防御注入漏洞：

• 使用特定语言的库函数来代替shell命令和系统调用；
• 对用户输入的信息进行严格检查和过滤 ：
  • 数据类型（字符串、整数等）正确吗？
  • 使用的是允许的字符集吗？
  • 输入满足格式要求吗？
  • ......
• 使用"最小权限"限制数据库用户的权限

🔎 如何判断是字符型注入还是数字型注入

🕤 2.1.4 实验：SQL注入

使用合天网安实验室进入WEB渗透测试实验平台，并进入SQL注入进阶实验

实例1、热身运动，不设防

关键代码：

$sql = "SELECT * FROM users where name='";
$sql .= $_GET ["name"]."'";
$result = mysql_query ($sgl);

实例1是字符串型注入

判断该网络后台数据库users表格的列数：为5列

判断该网络后台数据库users表格的每一列的数据类型

获取该网络后台数据库的数据库名

实例2、节约是种美德，少用空格

关键代码：

if (preg_match ( '/ /', $_GET ["name"])){
	die("ERROR NO SPACE");
}
$sql = "SELECT * FROM users where name='";
$sql .= $_GET ["name"]."'";
$result = mysql_query ($sql);

上述步骤与实例1基本相同，提示：URL中%20表示空格，可替代成%a0，%a0在Mysql中为换行符。注释指令可用#并用%23编码进行替代。

🕘 2.2 跨站脚本（XSS）攻击及防范

定义：跨站脚本(XSS)漏洞发生在应用使用用户提供的数据并发送给web浏览器而未经第一次验证或编码的时候。XSS允许攻击者在受害者的浏览器中执行脚本，这可以劫持用户会话、篡改网站、可能引入蠕虫等。

🕤 2.2.1 工作原理

原理：输入插入包含有JavaScript或其它恶意脚本的HTML标签代码。

<script>alert(XSS)</script>

问题根源：不当的服务器端输入检查，从而允许用户输入可被客户端浏览器解释的脚本命令。

XSS是最普遍的Web程序安全问题。

DOM，文件对象模型，Document Object Model.是给HTML和xml文件使用的一组API，是建立网页与Script语言沟通的桥梁，比如table对象代表HTML中的表格，可以由JavaScript脚本取用

🕤 2.2.2 反射式XSS

• 也称为非持久性 跨站脚本攻击，是一种最常见的跨站脚本攻击类型。
• 与本地脚本漏洞不同的是Web客户端使用Server端脚本生成页面为用户提供数据时，如果未经验证的用户数据 被包含在页面中而未经HTML实体编码，客户端代码便能够注入到动态页面中。
• 在这种攻击模式下，Web程序不会存储恶意脚本，它会将未经验证的数据通过请求发送给客户端，攻击者就可以构造恶意的URL链接或表单并诱骗用户访问，最终达到利用受害者身份执行恶意代码的目的。

例子：

(1) Alice经常浏览Bob建立的网站。Bob的站点运行Alice使用用户名/密码进行登录，并存储敏感信息(比如银行帐户信息)；

(2) Charly发现Bob的站点包含反射性的XSS漏洞；

(3) Charly编写一个利用漏洞的URL，并将其冒充为来自Bob的邮件发送给Alice；

(4) Alice在登录到Bob的站点后，浏览Charly提供的URL；

(5) 嵌入到URL中的恶意脚本在Alice的浏览器中执行，就像它直接来自Bob的服务器一样。此脚本盗窃敏感信息(授权、信用卡、帐号信息等)，然后在Alice完全不知情的情况下将这些信息发送到Charly的Web站点。

🕤 2.2.3 储存式XSS

储存式跨站脚本攻击，也称为持久性跨站脚本攻击。如果Web程序允许存储用户数据 ，并且存储的输入数据没有经过正确的过滤，就有可能发生这类攻击。

在这种攻击模式下，攻击者并不需要利用一个恶意链接，只要用户访问了储存式跨站脚本网页，那么恶意数据就将显示为网站的一部分并以受害者身份执行。

🕤 2.2.4 DOM式XSS

DOM式XSS 攻击并不是按照"数据是否保存在服务端"划分的，它是反射式XSS 的一种特例，只是由于DOM式XSS的形成原因比较特殊，因此把它单独作为一个分类。

DOM式XSS 攻击是通过修改页面DOM节点数据信息而形成的。看下面的代码。

<script
  function test(){
   var str = document.getElementById("input").value;
   document.getElementById("output").innerHTML="<a href="+str+"">test</a>";
   }
</script>
<div id="output"></div>
<input type="text" id="input" size=50 value=""/>
<input type="button" value="提交" onclick="test()"/>

如果构造数据"' onclick='javascript:alert(/xss/)"，那么最后添加的html代码就变成了"<a href=' ' onclick='javascript:alert(/xss/)'>test</a>"，插入一个onclick事件，点击提交按键，那么就会发生一次DOM式xss攻击。

🕤 2.2.5 防御XSS

对Web应用程序的所有输入进行过滤 ，对危险的HTML字符进行编码：

• '<' , '>' → '&lt;' , '&gt;'
• '(' , ')' → '(' , ')'
• '#' , '&' → '#' , '&'

对用户，谨防不明链接；

防止访问已知的恶意网站；

执行手工或自动化代码扫描，确定并消除潜在的XSS漏洞。

🕤 2.2.6 实验：XSS攻击

尝试构造语句使浏览器执行弹出对话框的脚本。

实例一、热身运动，不设防

关键代码：

<?php
	echo $_GET["name"];
?>

实例二、小写不行，就大写吧

关键代码：

	$name = $_GET["name"];
	$name = preg_replace("/<script>/", ""，$name);
	$name = preg_replace("/<\/script>/",""，$name);
echo $name;

实例三、大写小写都不行，看你怎么办？

关键代码：

	$name = $_GET[ "name"];
	$name = preg_replace( " /<script>/i",""，$name);
	$name = preg_replace( " /<\/script>/i",""，$name);
echo $name;

实例四、换一个角度，阳光依旧

关键代码：

if (preg_match('/script/i'，$_GET["name"])) {
	die("error");
}

实例五、限制了我的左手，我还有右手

关键代码：

if (preg_match('/alert/i'，$_GET["name"])) {
	die("error");
}

实例六、大胆去思考，小心去求证

关键代码：

<script>
	var $a= "<?php echo $_GET["name"]; ?>";
</script>

🕘 2.3 Cookie欺骗及防范

🕤 2.3.1 伪造Cookie信息

伪造Cookie信息，绕过网站的验证过程，不需要输入密码，就可以登录网站，甚至进入网站管理后台

网站登录验证代码：

<%
if request.Cookies("lunjilyb")("username")=""then response.redirect "login.asp"	/* 如果用户名为空，就
跳转到登录界面*/
endif
if request.Cookies("lunjilyb")("password")=""then response.redirect "login.asp"   /* 如果口令为空，就跳转到登录界面*/
endif
if request.Cookies("lunjilyb")("randomid")<>12 then response.redirect "login.asp"   /* 如果randomid值不等于12，就跳转到登录界面*/
endif
%>

利用request.Cookies语句分别获取Cookies中的用户名、口令和randomid的值。如果用户名或口令为空或randomid值不等于12就跳转到登录界面。也就是说，程序是通过验证用户的Cookie信息来确认用户是否已登录。然而，Cookie信息是可以在本地修改的，只要改后的Cookie信息符合验证条件（用户名和口令不空且randomid值等于12），就可进入管理后台界面。

判断是否有删帖权限的代码：

if Request.Cookies("power")="" then
  response.write"<SCRIPT 1anguage=JavaScript>alert('你还未登录论坛! ');</SCRIPT>"
  response.end
else
 if Request.Cookies("power')<500 then
   response.write"<SCRIPT 1anguage=JavaScript>alert('你的管理级别不够! );</SCRIPT>"
   response.redirect"http://cnc.cookun.com"
   response.end
 endif
endif

只要Cookie中的power值不小于500，任意用户都可以删除任意帖子。同样可以利用上面介绍的方法进行Cookie欺骗攻击面

上面介绍的两个攻击例子之所以成功，是因为在Cookie中保存了用户名、口令以及权限信息而留下了安全隐患。

• 安全原则：一般情况下，网站会话管理机制仅将会话ID保存至Cookie，而将数据本身保存在Web服务器的内存或文件、数据库中

🕤 2.3.2 监听Cookie来实现会话劫持

如果Cookie中没有设置安全属性secure"，则Cookie内容在网络中用明文传输，攻击者监听到Cookie内容后可以轻松实现会话劫持

Q：为什么会不设置安全属性？

A：不设置Cookie安全属性的原因主要有两种：一种是Web应用开发者不知道安全属性或不愿意使用安全属性；第二种是设置安全属性后应用无法运行。

🕘 2.4 CSRF攻击及防范

定义：CSRF（跨站请求伪造）攻击迫使已登录的受害者浏览器向易受攻击的Web应用程序发送预先验证的请求，然后强制受害者浏览器执行对攻击者有利的恶意操作。

现有银行的网银交易流程要比例子复杂得多，同时还需要USB key、验证码、登录密码和支付密码等一系列安全信息，一般并不存在CSRF安全漏洞，安全是有保障的。

重大的差别：

• CSRF利用的是Web服务器端的漏洞
• XSS利用的是Web客户端的漏洞

XSS攻击是实施CSRF攻击前的一个重要步骤：

• 攻击者通过XSS攻击获取有用的攻击信息，比如通过XSS伪造一个提示用户输入身份信息的表单。

防御CSRF攻击：

• 设定短暂的可信用户会话时间，完成任务后记得退出可信会话，删除所有cookie；
• 每次提出一个可信行为时，对发出请求的用户进行验证；
• 让网站记住登录用户名和密码时要小心。留在客户端的登录信息可能会攻击者加以利用；
• 在URL和表单中增加的每个请求，必须提供基本会话令牌以外的每个请求用户验证；
• 从Web应用程序中删除所有XSS漏洞。

	嵌入机密信息（令牌）	再次认证（输入密码）	检查Referer
工作原理	在访问需防范CSRF的页面（登录、订单确认、密码修改确认页面等）时需要提供第三方无法知晓的机密信息（令牌，token）。假设请求通过POST方式提交，则可以在相应表单中增加一个隐藏域：<input type="hidden" name="_token" value="tokenvalue"/> token值由服务端生成，表单提交后token的值通过POST请求与参数一同带到服务端，并在服务端进行token校验，如果请求中没有token或者token内容不正确，则认为是CSRF攻击而拒绝该请求。每次会话可以使用相同的token，会话过期，则token失效，攻击者因无法获取到token，也就无法伪造请求	执行操作前让用户再次进行认证（如输入密码），以确认请求是否由用户自愿发起的	在通常情况下，访问一个安全受限页面的请求都来自于同一个网站。Referer 记录了HTTP请求的来源地址，检查Referer值是否是执行页面的上一个页面（输入页面或确认页面等），如果不是则很可能是CSRF攻击

🕘 2.5 目录遍历及其防范

许多Web应用支持外界以参数的形式来指定服务器上的文件名，如果服务器在处理用户请求时不对文件名进行充分校验，就可能出问题，如：

• 文件被非法获取，导致重要信息被泄露；
• 文件被篡改，如篡改网页内容以发布不实消息，设置圈套将用户诱导至恶意网站，篡改脚本文件从而在服务器上执行任意脚本等；
• 文件被删除，如删除脚本文件或配置文件导致服务器宕机等

一般来说，如果Web应用满足以下3个条件时，就有可能产生目录遍历漏洞

• 外界能够指定文件名
• 能够使用绝对路径或相对路径等形式来指定其它目录的文件名
• 没有对拼接后的文件名进行校验就允许访问该文件

<?php
	define('TMPLDIR','/var/www/example/tmp1');
	$tmp1 -$_GET( 'template');
?>
<body>
<?php readfile(TMPLDIR, $tmp1,".html'); ?>
</body>

http://example.cn/example/ex.php?template=../../../../etc/hosts%00

将显示/etc/hosts文件内容

防御：

• 避免由外界指定文件名
  • 将文件名固定，保存在会话变量中，不直接指定文件名，而是使用编号等方法间接指定
• 文件名中不允许包含目录名
  • 不同系统中表示目录的字符有所不同，常见的有：/、\、:等
• 限定文件中仅包含字母或数字
  • 有些攻击使用不同的编码转换进行过滤性的绕过，如通过对参数进行URL编码来绕过检查
    downfile.jsp?filename= %66%61%6E%2E%70%64%66

🕘 2.6 操作系统命令注入及防范

很多Web应用编程语言支持应用通过Shell执行操作系统（OS）命令。通过Shell执行OS命令，或开发中用到的某个方法在其内部使用了Shell，就有可能出现恶意利用Shell提供的功能来任意执行OS命令的情况，这就是OS命令注入。

// 页面功能是发送电子邮件( sendmai1.htm1)
<body>
<form action ="send.php" method="POST">
请输入您的邮箱地址<br>
邮箱地址<input type ="text" name ="mail"<br>
邮件内容<textarea name ="con" cols = "20" rows = "3"></textarea><br>
<input type = "submit" value ="发送">
</form>
</body> // sendmail.html结束

// 接收页面的处理脚本(send.php)
<?php
	$mail = $_POST['mail'];
	// 调用OS命令sendmail将邮件发送到表单中填入的邮件地址$mail
	// 邮件信息保存在template.txt中
	system("/usr/sbin/sendmail -I <template.txt $mail");
	// 省略代码
<body>
	邮件已发送
<body> //send.php结束

如果用户在邮箱地址处输入的是正常的邮箱地址，该页面将给该邮箱发送一封正常的电子邮件。但是，如果攻击者在邮箱地址处输入的是以下内容:
list@example.com; cat /etc/passwd

则在页面上点击"发送"按钮后，页面上将显示的是系统口令文件/etc/passwd 的内容。此处攻击者只是用cat命令显示文件内容，他也完全可以用Web应用的用户权限执行任何操作系统命令，如删除文件、下载文件、执行下载来的恶意软件等。

上述攻击成功的主要原因是Shell支持连续执行多条命令，如Unix操作系统Shell中使用分号；或管道|等字符支持连续执行多条命令，Windows操作系统cmd.exe使用&符号来连接多条命令。这些符号一般称为Shell的元字符，如果OS命令参数中混入了元字符，就会使攻击者添加的操作系统命令被执行，这就是OS注入漏洞产生的原因

OS命令注入攻击的一般流程为：

1. 从外部下载攻击用软件；
2. 对下载来的软件授予执行权限；
3. 从内部攻击操作系统漏洞以取得管理员权限；
4. 攻击者在Web服务器上执行攻击操作，如：浏览、篡改或删除Web服务器内的文件，对外发送邮件，以此服务器作跳板攻击其他服务器等。

OS命令注入攻击防御策略：

• 选择不调用操作系统命令的实现方法，即不调用Shell功能，而用其它方法实现；
• 避免使用内部可能会调用Shell的函数；
• 不将外部输入的字符串作为命令行参数；
• 使用安全的函数对传递给操作系统的参数进行转义，消除Shell元字符带来的威胁。由于Shell转义规则的复杂性以及其它一些环境相关的原因，这一方法有时很难完全凑效。

🕘 2.7 HTTP消息头注入攻击及防范

指在重定向或生成Cookie时，基于外部传入的参数生成HTTP响应头：

• HTTP响应头信息一般以文本格式逐行定义消息头，即消息头之间互相以换行符隔开。攻击者可以利用这一特点，在指定重定向目标URL或Cookie值的参数中插入换行符且该换行符又被直接作为响应输出，从而在受害者的浏览器上任意添加响应消息头或伪造响应消息体：生成任意Cookie，重定向到任意URL，更改页面显示内容，执行任意JavaScript而造成与XSS同样效果

看下面的例子
http://example.com/web/in.cfg?url=http://example.com/%0D%0ALocation: + http://trap. com /web/attack.php

执行之后，浏览器会跳转到恶意网站trap.com/web/attack.php，而不是期望的正常网站http://example.com。造成这一结果的主要原因是，CGI脚本里使用的查询字符串url中包含了换行符（%0D%0A）。出两个消息头：

Location: http://example.com

Location: http://trap.com/web/attack.php

采用类似方法可以生成任意Cookie，看下面例子
http://example.com/web/in.cfg?url=http://example.com/web/exampple.php%0D%0ASet-Cookie: + SESSID=ac13rkd90

执行之后，两个消息头：

Set-Cookie: SESSID=ac13rkd90

Location: http://example.com/web/exampple.php

防御：

• 不将外部传入参数作为HTTP响应消息头输出，如不直接使用URL指定重定向目标，而是将其固定或通过编号等方式来指定，或使用Web应用开发工具中提供的会话变量来转交URL；
• 由专门的API来进行重定向或生成Cookie，并严格检验生成消息头的参数中的换行符

🕘 2.8 其他攻击

🕤 2.8.1 恶意文件执行

定义：易受远程文件包含（RFI）攻击的代码允许攻击者包含恶意代码和数据，从而导致毁灭性的攻击，如服务器完全被攻陷。恶意文件执行攻击会影响 PHP、XML 和任何接受用户文件名或文件的框架。

• 恶意文件执行漏洞也称为不安全的远程文件包含漏洞；
• 需要用户提供输入文件名的Web程序容易受到攻击：如果对用户输入不验证，攻击者可借此操控Web程序执行系统程序或外部URL；
• 允许上传文件给Web程序带来的危害更大
  • 可以将可执行代码放置到Web应用中去；
  • 可以替换Session文件、日志文件或认证令牌

防御：

• 禁止用户输入被用作输入文件片断；
• 对于必须要用户输入文件名、URL的地方，执行严格的检查验证输入合法性；
• 文件上传的处理要非常小心：
  • 文件只允许上传到webroot目录以外的目录中，这样能防止文件被执行；
  • 限制或隔离Web程序对文件的访问权限。

🕤 2.8.2 不安全的直接对象引用

定义：当开发人员将内部实现对象的引用（例如文件、目录、数据库记录或键）暴露为URL或表单参数时，就会发生直接对象引用。攻击者可以操作这些引用，未经授权访问其他对象。

• 不安全的直接对象引用漏洞也常称为目录遍历漏洞；
• Web程序常常会暴露内部对象，包括：
  • 文件或目录
  • URL
  • 数据库口令
  • 数据库的一些对象名称，比如表名
• 如果访问控制配置不合理，攻击者就可以不经授权地操作这些暴露的内部对象。

防御：

• 锁定Web目录。使得通过网络访问Web服务器的用户都不能访问除专门用于存放Web内容的目录以外的目录；
• 对于每一次对象引用都要重新验证授权；
• 禁止通过参数暴露内部对象；
• 建议使用间接映射的方法取代简单的直接对象引用，比如：
  http://www.example.com/application?file=1

🕤 2.8.3 信息泄露和不当的错误处理

定义：应用程序可能会无意间泄露关于其配置、内部工作原理或违反隐私的信息，这可能是由于应用程序存在各种问题。攻击者利用这些弱点来窃取敏感数据或进行更严重的攻击。

敏感信息泄露常常细微难以察觉

常见的脆弱点：

• 查明堆栈跟踪：为程序员提供详尽的信息，说明错误发生前调用了哪些程序或函数。相同的信息还可为计算机罪犯提供函数、对象名称，以及其它设计针对报告错误的系统的攻击的相关情况。
• SQL状态信息：揭示数据库、字段和表名称------在计划实施SQL注入之类的攻击时，与数据库有关的信息十分重要
• 登录信息：登录失败后，通知用户是否用户ID或密码出错------登录失败可能是由于ID或密码错误造成的。这为一个对关键资产发动暴力攻击的攻击者提供重要信息。
• 授权信息：确认某个文件------如果未获得授权的用户企图访问某个文件，返回的错误消息会告诉她没有取得访问那个资源的授权。如果她是一名试图定位某个包含敏感信息的文件的攻击者，错误消息就为她提供了肯定信息。

示例1：

Microsoft OLE DB Provider for ODBC Drivers error '80004005' 
[Microsoft][ODBC Microsoft Access 97 Driver] Can't open database 'VDPROD'.

示例2：

java.sql.SQLException: ORA-00600: internal error code,
arguments: [ttcgnd-1], [0], [], [], [],
at oracle.jdbc.dbaccess.DBError.throwSqlException (DBError.java:169) 
at oracle.jdbc.ttc7.TTIoer.processError (TTIoer.java:208)

错误处理信息对于Debug非常有用，但是为攻击者提供了太多潜在可用的攻击信息！

防御：

• 每个应用程序都应包含一个标准的错误处理框架来处理异常：禁止显示堆栈跟踪、数据库访问、协议等相关的信息；
• Web程序应只提供尽量简短、"刚好够用"的错误处理信息给用户；

🕤 2.8.4 认证和会话管理不完善

定义：账户凭据和会话令牌通常没有得到适当的保护。攻击者通过窃取密码、密钥或身份验证令牌来冒充其他用户的身份。

会话（Session）管理

• HTTP/HTTPS是"无状态"协议。意味着每一次用户请求都需要认证
• 会话管理解决了这样的问题：当一个用户得到服务器认证后，服务器如何识别和处理这个认证用户接下来的请求
• Web程序一般会提供内置的会话跟踪方法，方便用户的使用；
• Web开发者常采用自己的策略来实现会话状态管理，可能会犯错误而导致安全问题。

会话管理：Session ID

• 唯一地标识用户
• 一个ID仅用于一次认证会话
• 由服务器生成
• 以如下的形式发送给客户端：
  • 隐式变量
  • HTTP cookie
  • URL查询串
• 服务器期待用户在下一次请求时发送同样的ID（用来标识用户已被认证）

会话管理：Session Hijacking

• Session ID可能被泄露和猜解，黑客可以：
  • 获取用户的帐号
  • 做任何受害者能做的事情：一个使用同样Session ID的攻击者将拥有和真正用户相同的特权。

认证和会话管理攻击流程：

防御：

• 使用长且复杂的随机Session ID，难以猜解；
• 对Session ID的传输、存储进行保护，防止被泄露和劫持；
• 使用SSL时，必须保护认证和Session ID两部分的内容；
• URL查询字符串中不要包含有User/Session任何信息。

🕤 2.8.5 不安全的加密存储

定义：Web程序很少正确使用加密功能来保护数据和凭据。攻击者利用弱保护的数据进行身份盗窃和其他犯罪活动，例如信用卡欺诈。

常见的问题：

• 对敏感信息没有加密；
• 继续使用已被证明加密强度不高的算法（ MD5, SHA-1, RC3, RC4, etc.）；
• 加密方法使用不安全，比如对加密口令的存储不加保护；
• 尝试使用自己发明的加密方法（实践证明这种方法比较糟糕！）。

示例：

防御：

• 如非必要，不要保存敏感信息；
• 确保所有的敏感信息都被加密，检查敏感信息的归档过程和政策；
• 只使用经过证明的标准加密算法；
• 小心存储口令、证书等信息。

🕤 2.8.6 URL访问缺少限制

定义：通常，应用程序仅通过防止向未经授权的用户显示链接或URL来保护敏感功能。攻击者可以利用此弱点直接访问这些URL并执行未经授权的操作。

当Web应用缺少对某些URL的访问限制，攻击者可以直接在浏览器中输入URL来访问。

比如：

• Add_account_form.php 在显示这个表单页时要先对用户的管理员角色进行验证；
• 表单填好后发送给add_acct.php执行添加帐号的功能；
• 如果不限制add_acct.php的直接访问，攻击者直接在浏览器中访问该页面，就绕过了权限检查。

防御：

• 从早期做起！
  • 从需求阶段就要制定详细的安全策略；
  • 从页面到每一个功能，都只由相应的经过认证的角色来访问；
  • 访问控制策略越简单越好。
• 彻底地测试！
  • 进行详尽地测试保证访问控制没有被旁路；
  • 尝试所有的非法访问；
  • 测试时不要跟随Web应用的正常工作流；

🕒 3. HTTPS

🕘 3.1 提出背景：不安全的通信

定义：当需要保护敏感通信时，应用程序经常无法加密网络流量。

存在的问题：

• 攻击者可以从网络上任何一个被攻陷的系统或设备上嗅探网络流量：Web流量往往是不加密的
• 使用SSL也可能遭受"中间人"攻击

🕘 3.2 防御

保证所有用来认证和传输敏感信息的连接都使用基于SSL/TLS的HTTPS

超文本传输安全协议（Hypertext Transfer Protocol Secure，HTTPS），是一种将HTTP和SSL（或TLS）结合来实现Web浏览器和服务器之间的安全通信协议，也称为HTTP over TLS，HTTP over SSL或HTTP Secure。基于SSL或TLS的HTTP并没有本质区别，都被称为HTTPS

🔎 【PPT分享】清华大学郑晓峰： 端到端安全协议的威胁、演进和部署

从用户使用的角度看，HTTP和HTTPS的主要区别是URL地址开始于http://还是https://

• 一个标准的HTTP服务使用80端口，而一个标准的HTTPS服务则使用443端口

当使用HTTPS时，下述通信内容被加密：请求的文件的URL，文件的内容 ，浏览器表单的内容 （由浏览器使用者填写），从浏览器发送到服务器或从服务器发送给浏览器的Cookie ，HTTP标题的内容

连接建立 ：

作为HTTP用户的代理程序（也是TLS的用户）首先向服务器的指定端口（443）发起TCP连接请求。成功建立TCP连接后，向服务器发送TLS ClientHello，开始TLS握手过程。当TLS握手过程完成后，用户将发起第一次HTTP请求。此时，所有HTTP协议数据都要以TLS应用数据的形式通过TLS记录协议加密传输。在此过程中，要遵守HTTP协议规范，包括保留连接。

Q：HTTP连接的含义？

A：HTTPS连接具体多个层面的意思。在HTTP层面，一个HTTP用户通过向下一层（TCP或SSL/TLS）发送一个连接请求来向服务器请求建立一条连接；在TLS层面，一个会话建立在一个TLS用户和一个TLS服务器之间，可以在任何时间支持一条或多条TLS连接。一条TLS连接请求的开始总是伴随着一条TCP连接的建立。

连接关闭 ：

关闭一条HTTPS连接要求关闭TLS与其对应的对端实体之间的连接，这意味着也要关闭TLS的下层TCP连接。在TLS层面，关闭连接的最好方式是两端都用TLS告警协议发出一个"close_notify"告警。在发出"close_notify"后，一个TLS实体会立即关闭该连接，而不会等待它的对等实体发来"close_notify"告警，从而可能造成"不完整的关闭"。

服务器端的HTTPS部署情况 ：

HSTS (HTTP Strict Transport Security)

• IETF提出的一种新的Web安全协议，其目的是强制客户端（如Web浏览器）使用HTTPS与服务器进行通信。使用HSTS协议的网站将保证浏览器始终使用HTTPS连接到服务器，不需要用户在浏览器的地址栏中手工输入HTTPS。当客户端通过HTTPS向服务器发出请求时，服务器在返回的超文本传输协议响应头中包含Strict-Transport-Security字段。
• HSTS可以用来抵御SSL剥离攻击（一种用来阻止浏览器与服务器之间创建HTTPS连接的中间人攻击方法，由Moxie Marlinspike在2009年的黑帽大会上提出），因为只要浏览器曾经与服务器创建过一次安全连接，之后浏览器会强制使用HTTPS，即使URL链接中的https被替换成了http

判断一个域名是否支持HTTPS：🔎 Internet.nl

有了HTTPS，即使被中间人攻击，也能防止攻击

• 2020.3.26 国内部分地区网络出现中间人攻击（通过骨干网络进行劫持 HTTPS的443端口）：GitHub、京东等被劫持。因证书不对，被浏览器阻止访问

🔎 国内部分地区网络出现中间人攻击：GitHub、京东等被劫持

🔎 域名注册商GoDaddy客服被钓鱼攻击，多家公司域名解析被篡改

🔎 HTTPS 劫持漫谈：代理劫持与透明劫持

简答题：小王某次出差住宿，利用酒店提供的Wi-Fi来上网，当他开始访问一个自己经常访问的网站时，浏览器却弹出类似"你的连接不是专用连接"，将鼠标放在浏览器地址栏的证书风险处，下拉显示"证书无效之类的信息"，如下图所示。浏览器提示用户"继续访问"还是"返回"。而自己平时在办公室访问该网站却没有出现该提示。请分析可能的原因。

答：最可能的原因是酒店在监听用户的上网，酒店使用自签名证书或浏览器不信任的CA颁发的证书作为中间人分别与浏览器与目标网站进行加密通信，解密、加密用户浏览器与目标网站之间的通信。

---

OK，以上就是本期知识点"Web应用安全"的知识啦~~ ，感谢友友们的阅读。后续还会继续更新，欢迎持续关注哟📌~

💫如果有错误❌，欢迎批评指正呀👀~让我们一起相互进步🚀

🎉如果觉得收获满满，可以点点赞👍支持一下哟~

❗ 转载请注明出处

作者：HinsCoder

博客链接：🔎 作者博客主页