什么是文件上传漏洞

文件上传漏洞是指
由于程序员在对用户文件上传部分的控制不足或者处理缺陷，而导致的用户可以越过其本身权限向服务器上上传可执行的动态脚本文件
这里上传的文件可以是木马，病毒，恶意脚本或者WebShell等。
这种攻击方式是最为直接和有效的，“文件上传”本身没有问题，有问题的是文件上传后，服务器怎么处理、解释文件。如果服务器的处理逻辑做的不够安全，则会导致严重的后果。

解析漏洞
攻击者在利用上传漏洞时，通常会与Web容器的解析漏洞配合在一起

造成文件上传漏洞的原因
对于上传文件的后缀名（扩展名）没有做较为严格的限制
对于上传文件的MIMETYPE(用于描述文件的类型的一种表述方法) 没有做检查
权限上没有对于上传的文件目录设置不可执行权限，（尤其是对于shebang类型的文件）
对于web server对于上传文件或者指定目录的行为没有做限制

防止上传漏洞两种策略
客户端检测：客户端使用JS检测，在文件未上传时，就对文件进行验证
服务器端检测：检测文件扩展名是否合法，检测文件中是否嵌入恶意代码

如何检验有没有解析漏洞
上传要求（正确的）的文件类型
上传带有脚本的伪造成 txt,jpg 文件上传验证

前端检测绕过方法
绕过前台脚本检测扩展名，就是将所要上传文件的扩展名更改为符合脚本检测规则的扩展名，通过工具，截取数据包，并将数据包中文件扩展名更改回原来的，达到绕过的目的
如果是JS脚本检测，在本地浏览器客户端禁用JS即可。可使用火狐浏览器的NoScript插件、IE中禁用掉JS等方式实现

检查扩展名
在文件被上传到服务端的时候，对于文件名的扩展名进行检查，如果不合法，则拒绝这次上传
检查扩展名是否合法的时候，有两种策略：
1.黑名单策略，文件扩展名在黑名单中的为不合法
2.白名单策略，文件扩展名不在白名单中的均为不合法
黑名单、白名单哪种更安全？
白名单策略是更加安全的，通过限制上传类型为只有我们接受的类型，可以较好的保证安全，因为黑名单我们可以使用各种方法来进行注入和突破
原理：当浏览器将文件提交到服务器端的时候，服务器端会根据设定的黑白名单对浏览器提交上来的文件扩展名进行检测，如果上传的文件扩展名不符合黑白名单的限制，则不予上传，否则上传成功

导致文件上传漏洞的根本原因在于服务把用户上传的本应是数据的内容当作了代码，一般来说，用户上传的内容都会被存储到特定的一个文件夹下，比如我们很多人习惯于放在 ./upload/ 下面要防止数据被当作代码执行，我们可以限制web server对于特定文件夹的行为
在默认情况下，对与 .php文件Apache会当作代码来执行，对于 html,css,js文件，则会直接由HTTP Response交给客户端程序对于一些资源文件，比如txt，doc，rar等等，则也会以文件下载的方式传送的客户端。我们希望用户上传的东西仅仅当作资源和数据而不能当作代码
因此可以使用服务器程序的接口来进行限制

防范文件上传漏洞常见的几种方法：
1.文件上传的目录设置为不可执行
只要web容器无法解析该目录下面的文件，即使攻击者上传了脚本文件，服务器本身也不会受到影响，因此这一点至关重要。
2.判断文件类型
在判断文件类型时，可以结合使用MIME Type、后缀检查等方式。在文件类型检查中，强烈推荐白名单方式，黑名单的方式已经无数次被证明是不可靠的。此外，对于图片的处理，可以使用压缩函数或者resize函数，在处理图片的同时破坏图片中可能包含的HTML代码。
3.使用随机数改写文件名和文件路径
文件上传如果要执行代码，则需要用户能够访问到这个文件。在某些环境中，用户能上传，但不能访问。如果应用了随机数改写了文件名和路径，将极大地增加攻击的成本。再来就是像shell.php.rar.rar和crossdomain.xml这种文件，都将因为重命名而无法攻击。
4.单独设置文件服务器的域名
由于浏览器同源策略的关系，一系列客户端攻击将失效，比如上传crossdomain.xml、上传包含Javascript的XSS利用等问题将得到解决。
-------------------------------------------------------------

XSS

又叫CSS（Cross Site Scripting），即跨站脚本攻击，指攻击者在网页中嵌入客户端脚本，通常是JavaScript编写的恶意代码，当用户使用浏览器被嵌入恶意代码的网页时，恶意代码将会在用户的浏览器上执行
产生的原因
 Web应用程序对用户的输入过滤不严而产生的

危害
网络钓鱼，包括窃取各类用户账号
窃取用户cookie
窃取用户浏览会话
强制弹出广告页面、刷流量
网页挂马
提升用户权限，进一步渗透网站
传播跨站脚本蠕虫等

类型
反射型XSS
存储型XSS
DOM XSS

反射型跨站脚本也称做非持久型、参数型跨站脚本、这类型的脚本是最常见的，也是使用最为广泛的一种
可以将恶意的脚本附加到URL地址的参数
例如：http://www.xxcc.com/search.php?key=“><script>alert(“xss”)</script>
一般使用将构造好的URL发给受害者，使受害者点击触发，而且只执行一次，非持久化
或者将恶意脚本附加到带参数的输出函数中

什么是存储型XSS
当用户提交一段XSS代码后，被服务器端接收并存储，当攻击者再次访问某个页面时，这段XSS代码被程序读出来响应给浏览器，造成XSS跨站攻击

什么情况容易出现存储型XSS
运行用户存储数据的Web应用程序

存储型XSS漏洞，一次提交之后，每当有用户访问这个页面都会受到XSS攻击，危害巨大。

手工检测
输入一些敏感字符，如“<、>、’、（）”，提交后查看HTML源代码，看这些是否被转义
全自动检测XSS
借助于扫描工具
awvs、netsparke、appscan、burpsuit、xsser、xsscrapy、brutexssr、OWASP Xenotix

通用的补充性防御手段 
在输出html时，加上Content Security Policy的Http Header 
（作用：可以防止页面被XSS攻击时，嵌入第三方的脚本文件等）
（缺陷：IE或低版本的浏览器可能不支持）
 2.在设置Cookie时，加上HttpOnly参数 
（作用：可以防止页面被XSS攻击时，Cookie信息被盗取，可兼容至IE6） 
（缺陷：网站本身的JS代码也无法操作Cookie，而且作用有限，只能保证Cookie的安全）
 3.在开发API时，检验请求的Referer参数 
（作用：可以在一定程度上防止CSRF攻击）
 （缺陷：IE或低版本的浏览器中，Referer参数可以被伪造）
-------------------------------------------------------------

什么是SQL注入漏洞

通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令

SQL 注入带来的威胁主要有如下几点
猜解后台数据库，这是利用最多的方式，盗取网站的敏感信息
绕过认证，例如绕过验证登录网站后台
注入可以借助数据库的存储过程进行提权等操作    

SQL注入方法
通过字符串注入
猜测：猜表名，猜列名，猜数据库名等等
后台身份验证绕过漏洞

实验步骤：
猜字段
猜数据库名字
猜用户名
猜数据库版本
猜当前操作系统
猜数据库表名
获取用户名和密码

如何防御
使用参数化的过滤性语句
输入验证
错误消息处理
加密处理
存储过程来执行所有的查询
使用专业的漏洞扫描工具
保数据库安全
-------------------------------------------------------------

什么是浏览器安全

浏览器端具备安全功能

为什么提浏览器安全
作为客户端，如果具备安全功能，就可以像安全软件一样对用户上网起到较好的保护作用
浏览器安全也成为浏览器厂商之间竞争的底牌，能够针对安全建立起技术门槛，以获得竞争优势

同源策略总结：
浏览器的同源策略是浏览器安全的基础，理解同源策略对于客户端脚本攻击有着重要意义。同源策略一旦出现漏洞被绕过，也将带来非常严重的后果，很多基于同源策略制定的安全方案都将失去效果

同源策略的意义
限制了来自不同源的“document”或脚本，对当前“document”读取或设置某些属性
举例：
如果没有同源策略，可能a.com的一段JS脚本，在b.com未曾加载此脚本时，也可以随意涂改b.com的页面（在浏览器的显示中）。为了不让浏览器的页面行为发生混乱，浏览器提出了“Origin”（源）这一概念来自不同Origin的对象无法互相干扰

为什么浏览器要使用同源策略
主要目的是为了安全，浏览器中JS的同源策略决定了，当浏览器认为来自不同源时，请求被拒绝
如果没有同源限制，在浏览器中的cookie等其他数据可以任意读取，不同域下的DOM任意操作，ajax任意请求其他网站的数据，包括隐私数据

挂马：在网页中插入一段恶意代码，利用浏览器漏洞执行任意代码的攻击方式，被称为“挂马”
“挂马”是浏览器需要面对的一个主要威胁，近年来，独立于杀毒软件之外，浏览器厂商根据挂马的特点研究出了一些对抗挂马的技术

典型对抗挂马的技术
多进程架构
将浏览器的各个功能模块分开，各个浏览器实例分开，当一个进程崩溃时，不会影响到其他的的进程
Google Chrome主要进程有：浏览器进程、渲染进程、插件进程、扩展进程等
插件进程如flash、java、pdf等于浏览器进程严格隔离，因此不会互相影响

沙箱（Sandbox）:泛指“资源隔离类模块”的代名词
设计沙箱的目的：
让不可信任的代码运行在一定的环境中，限制不可信任的代码访问隔离去之外的资源
如果一定要跨越沙箱边界产生数据交换，则只能通过指定的数据通道，比如经过封装的API来完成，在这些API中会严格检查请求的合法性

很多时候“挂马”攻击在实施时会在一个正常的网页中通过<script>或者<iframe>等标签加载一个恶意网址
除了加载恶意网址外，浏览器端还有没有别的威胁
钓鱼网站
诈骗网站
为了保护用户安全，浏览器厂商纷纷推出各自的拦截恶意网址功能
目前各个浏览器的拦截恶意网址的功能都是基于“黑名单”的
-------------------------------------------------------------

什么是点击劫持（ClickJacking）

攻击者使用一个透明的、不可见的iframe,覆盖在一个网页上,然后诱使用户在该网页上进行操作，此时用户将在不知情的情况下点击透明的iframe页面。通过调整iframe的位置，可以诱使用户恰好点击在iframe页面的一些功能性按钮上

主要有：
点击劫持概述
攻击者使用一个透明的、不可见的iframe,覆盖在一个网页上,然后诱使用户在该网页上进行操作，此时用户将在不知情的情况下点击透明的iframe页面。通过调整iframe的位置，可以诱使用户恰好点击在iframe页面的一些功能性按钮上
Flash点击劫持
攻击者通过Flash构造出点击劫持
图片覆盖攻击
通过调整图片的style使得图片能够覆盖在他所指定的任意位置

触屏劫持是一种视觉上的欺骗，如何防御？
通过禁止跨域的iframe来防范
写一段 JS 代码，以禁止iframe的嵌套，这种方法叫frame busting(框架破坏),如 :
if(top.location != location){
    top.location = self.location;
}

其他防御方法
HTML5中iframe的sandbox属性
IE中iframe的security属性等，都可以限制iframe页面中JS脚本的执行，从而使得frame busting失效
Firfox中的“Content Security Policy”以及Firfox的NoScript扩展也能有效防御触屏劫持

触屏劫持相对于XSS、CSRF来说，因为需要诱使用户与页面产生交互行为，因此实施攻击的成本更高，在网络犯罪中比较少见
但是，未来触屏劫持仍然有可能被攻击者利用在钓鱼、欺诈和广告作弊等方面，不可不察
-------------------------------------------------------------

什么是CSRF

全名：Cross Site Request Forgery（跨站点请求伪造）
攻击者通过盗用身份，并用盗用来的身份发送恶意请求
CSRF能够做什么?
以盗用者身份发送邮件，发消息，盗取账号，甚至用于购买商品，虚拟货币转账等等
 造成的问题包括：个人隐私泄露以及财产安全

怎样防御CSRF攻击？
CSRF的防御可以从服务端和客户端两方面着手
防御效果是从服务端着手效果比较好
现在一般的CSRF防御也都在服务端进行
服务端进行CSRF防御
服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数
在表单里增加Hash值，以认证这确实是用户发送的请求；然后在服务器端进行Hash值验证
方法二：验证码
方法三：One-Time Tokens(不同的表单包含一个不同的伪随机值)
在实现One-Time Tokens时，需要注意一点： “并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单，CSRF保护措施不应该影响到他对任何表单的提交
如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况?
用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点
-------------------------------------------------------------

HTML5新增一些标签和属性，使得XSS等Web攻击产生了新的变化

iframe的sandbox
<iframe>标签一直以来都存在隐患，如：挂马、XSS、点击劫持等；浏览器厂商也一直在想办法限制iframe执行脚本的权限，比如：跨窗口访问会有限制，以及IE中支持security属性限制脚本的执行
HTML5中，专门为iframe定义了一个新的属性，叫sandbox。使用sandbox这一属性后，<iframe>标签加载的内容将被视为一个独立的“源”，其中的脚本将被禁止执行，表单将被禁止提交，插件被禁止加载，指向其他浏览器对象的链接也会被禁止

Cross—Origin—Resource Sharing
浏览器的同源策略限制了脚本的跨域请求，但互联网的发展趋势越来越开放，因此跨域访问的需求也变得越来越迫切，同源策略给Web开发者带来了很多困扰
开发者不得不想方设法地实现一些“合法”的跨域技术，由此诞生了jsonp、iframe跨域等技巧，W3C委员会决定制定一个新的标准来解决日益迫切的跨域访问问题
 

文章来源: fantianzuo.blog.csdn.net，作者：兔老大RabbitMQ，版权归原作者所有，如需转载，请联系作者。

原文链接：fantianzuo.blog.csdn.net/article/details/103169607