安全相关
XSS
XSS是一种代码注入攻击，攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行，利用这些恶意代码窃取用户数据（cookie、sessionID等）并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作
- 反射型xss（非持久型）：攻击的代码放在url中，提交到服务器，服务器将恶意代码从url中取出，拼接在html中返回给浏览器，浏览器解析执行
- 存储型xss（持久型）：攻击的代码在目标网站的数据库中，用户打开目标网站时，服务端将恶意代码从数据库取出，拼接在html中返回给浏览器，浏览器解析执行，混在其中的恶意代码也被执行，常见的如论坛发帖
- DOM型XSS：前端代码本身不够严谨，把不可信的数据当做代码执行了，取出和执行恶意脚本代码由浏览器端完成，属于前端js自身的安全漏洞，其他两者属于服务端的安全漏洞
防御:
-
输入过滤，有很大的不确定性和乱码问题，但是对于明确的输入类型如表单验证相关的，输入过滤是必要的
-
纯前端渲染： 浏览器先加载一个静态html，不包含任何业务相关的数据，ajax请求数据
-
输出编码：转义html标签文字内容和属性值、css内联样式、内联js、内联json、a标签的href
-
设置cookie为http-only：只要cookie含有http-only字段，那么任何javaScript脚本都没有权限读取这条cookie的内容
-
验证码：防止用户窃取信息之后冒充用户提交危险操作
-
防御DOM型XSS：
- 避免将不可信的数据拼接到字符串传入某些api：
location、onclick、onerror、onload、onmouseover等内联事件监听器，a标签的href属性，js的eval()、setTimeout()、setInterval()等能把字符串作为代码运行的api - 减少使用
.innerHTML，尽量使用.textContent - react中，注意
dangerouslySetInnerHTML
- 避免将不可信的数据拼接到字符串传入某些api：
-
使用内容安全策略（CSP）是对抗XSS的深度防御策略
- CSP是一个额外的安全层，用于检测并削弱某些特定类型的攻击，包括XSS和数据注入攻击等，完全向后兼容
- CSP通过指定有效域（浏览器认可的可执行脚本的有效来源），使服务器管理者有能力减少或消除XSS攻击所依赖的载体。一个CSP兼容的浏览器将会仅执行从白名单域获取到的脚本文件，忽略其他所有的脚本 (包括内联脚本和HTML的事件处理属性)。作为一种终极防护形式，始终不允许执行脚本的站点可以选择全面禁止脚本执行
- 使用：
- 需要服务器返回
Content-Security-Policy头部 - 设置meta：
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
- 需要服务器返回
- 主要作用：
- 禁止加载外域代码，防止复杂的攻击逻辑
- 禁止外域提交，网站被攻击后，用户的数据不会泄露到外域
- 禁止内联脚本执行（规则较严格，目前github在使用）
- 禁止未授权的脚本执行（新特性）
- 合理使用上报可以及时发现XSS，利于尽快修复问题
XSS检测
- 使用通用XSS攻击字符串手动检测XSS漏洞
jaVasCript:/*-/*/`/'/"/**/(/ */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/–!>\x3csVg/<sVg/oNloAd=alert()//>\x3e`- 它能够检测到存在于 HTML 属性、HTML 文字内容、HTML 注释、跳转链接、内联 JavaScript 字符串、内联 CSS 样式表等多种上下文中的 XSS 漏洞，也能检测
eval()、setTimeout()、setInterval()、Function()、innerHTML、document.write()等 DOM 型 XSS 漏洞，并且能绕过一些 XSS 过滤器 - 只要在网站的各输入框中提交这个字符串，或者把它拼接到URL参数上，就可以进行检测了
- 使用扫描工具自动检测XSS漏洞，如 Arachni、Mozilla HTTP Observatory、w3af 等
CSRF
跨站请求伪造
https://juejin.cn/post/6844903689702866952
GET类型的CSRF:
-
get类型的csrf非常简单，只需要一个http请求：
<img src="http://bank.example/withdraw?amount=10000&for=hacker" > -
当受害者访问含有这个img的页面之后，浏览器会自动向
<img src="http://bank.example/withdraw?amount=10000&for=hacker" >发出一次http请求，bank.example就会收到包含受害者登录信息的一次跨域请求
POST类型的CSRF:
-
通常使用的是一个自动提交的表单，如：
<form action="http://bank.example/withdraw" method=POST> <input type="hidden" name="account" value="xiaoming" /> <input type="hidden" name="amount" value="10000" /> <input type="hidden" name="for" value="hacker" /> </form> <script> document.forms[0].submit(); </script> -
受害者访问页面，表单就会自动提交，相当于模拟用户完成了一次POST请求
-
post类型的攻击通常比get要求严格一些，但仍不复杂，任何个人网站、博客、黑客上传的网站都可能是发起攻击的来源
链接类型的CSRF：
-
不常见，并且需要用户点击链接才会触发
-
通常是在论坛中发布的图片中有恶意链接，或者以广告的形式诱导用户
<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank"> 重磅消息！！ <a/>
CSRF的特点：
- 攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生
- 攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据
- 整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”
- 跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪
根据CSRF（通常）发生在第三方域名和CSRF攻击者不能获取到cookie信息，只能使用的特点，我们可以：
- 阻止不明外域的访问：同源检测（Origin Header和Referer Header）、Samesite Cookie
- 提交时要求附加本域才能获取的信息：token、双重cookie验证
其他：
-
验证码
-
token，服务端收到请求后，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝请求。这种方法要比检查Referer要安全一些（token可以在用户登录后产生并放于session中，然后在每次请求的时候把token从session中拿出，与请求中的token进行比对）
-
验证referer：在http请求中，每个异步请求都会携带Origin Header和Referer Header，用来标记来源域名， 并且不能由前端自定义内容，服务器可以通过解析这两个Header中的域名，确定请求的来源域。下例中如果是来源于银行，则继续转账，否则忽略请求
-
前端防御：设置cookie的SameSite属性值（Strict、Lax、None），标识在非同源的请求中，是否可以带上cookie，但要注意浏览器是否支持SameSite属性
-
分布式校验：
- 大型网站中，服务器通常不止一台，由于session默认存储在单机服务器内存中，因此同一个用户发起的http请求可能会先后落到不同的服务器上，导致后面的http请求无法访问到之前储存在服务器中的session数据（因此在分布式集群中CSRF token需要存储在Redis之类的公共存储空间）
- 但是session存储、读取和验证token会引起较大的复杂度和性能问题，目前很多网站采用Encrypted Token Pattern方式。这种方法的token是由userId、时间戳和随机数通过加密的方法生成的，在校验时无需读取存储的token，只需要再计算一次即可
- token解密之后，将token中包含的userId和当前登录的userId进行比较，并将时间戳与当前时间戳进行比较，验证token的有效性
-
双重cookie验证：利用csrf不能获取到用户cookie的特点，可以要求ajax和表单请求携带一个cookie中的值
- 在用户访问网站页面时，向请求域名注入一个cookie，内容为一个随机字符串
- 在发起请求的时候，取出注入的cookie，并添加到url的参数中
- 后端验证cookie中的字段与url参数中的字段是否一致，不一致则拒绝
- 简单但是安全性没有token高，由于任何跨域都会导致前端无法获取Cookie中的字段（包括子域名之间）
具体示例：
- 用户登录了A网站，有了cookie，没有退出登录，访问B网站，B网站又给A的某个接口发送请求，这时候就会带上A网站的cookie形成攻击（例如：你有一个银行网站，域名为www.a-bank.com，你登录银行网站之后，调用/transfer接口给对方账户转账，之后没有退出登录，接着访问了一个恶意网站，恶意网站显示了一个按钮，其实是一个表单，隐藏了其他内容，表单提交接口刚好是银行转账接口https://www.a-bank.com/transfe，点击按钮之后，请求发送到你的银行网站，此时会携带上www.a-bank.com的cookie，你的银行网站会根据携带的cookie判断用户为登录状态，继续执行转账操作，将money转到黑客账户上了）
点击劫持
点击劫持是一种视觉欺骗的攻击手段，攻击者将需要攻击的网站通过iframe嵌套的方式嵌入自己的网页中，并将iframe设置为透明，在页面中透出一个按钮诱导用户点击
X-FRAME-OPTIONS
X-FRAME-OPTIONS是一个http响应头，就是为了防御用iframe嵌套的点击劫持攻击，该响应头有三个值可选，分别是：
-
DENY，表示页面不允许通过iframe的方式展示
-
SAMEORIFIN，表示页面可以在相同域下通过iframe的方式展示
-
ALLOW-FROM，表示可以在指定来源的iframe中展示
中间人攻击
中间人攻击是攻击双方同时与服务端和客户端建立了连接，并让对方认为连接是安全的，但是实际上整个通信过程都被攻击者控制了。攻击者不仅能获得双方的通信信息，还能修改通信信息
通常来说不建议使用公共WiFi，因为很可能发生中间人攻击的情况，如果通信过程中涉及到了某些敏感信息，就完全暴露给攻击方了
防御：
- 只需要增加一个安全通道来传输信息，https就可以用来防御中间人攻击（在SSL/TLS握手过程中验证服务器证书）
- 但是如果没有完全关闭http访问的话，攻击方可以通过某些方式将https降级为http从而实现中间人攻击
SYN攻击
在TCP建立连接的过程中，假如攻击者在短时间内伪造不同IP地址的SYN报文，服务器每收到SYN报文就会进入RCVD状态，但服务端发送的ACK+SYN报文，无法得到未知IP主机的ACK应答，时间一长就会占满服务端的SYN接收队列，使得服务器不能正常为用户服务
SYN队列即半连接队列，Accept队列即全连接队列，SYN攻击的是SYN队列
防御
-
修改Linux内核参数，控制队列大小和当队列满时应做什么处理
-
net.core.netdev_max_backlog：控制队列的最大值，当网卡接收数据包的速度大于内核处理的速度时，会有一个队列保存这些数据包 -
net.ipv4.tcp_max_syn_backlog：SYN_RCVD状态连接的最大个数 -
net.ipv4.tcp_abort_on_overflow：超出处理能力时，对新的SYN直接返回RST，丢弃连接
-
-
net.ipv4.tcp_syncookies = 1：当SYN队列被占满时，启动cookie-
-
服务器收到SYN报文，将其加入SYN队列，发送SYN+ACK，收到ACK之后，从SYN队列中移到Accept队列，应用通过调用accept() socket接口取出连接
-
如果应用程序过慢，就会导致Accept队列被占满，以至于SYN队列中的报文无法移入Accept队列，最后报文不能进入SYN队列
-
-
如果不断受到SYN攻击，就会导致SYN队列被占满，且无法收到未知IP的ACK报文，导致Accept队列空
-
启动cookie应对攻击：
-
-
当SYN队列满之后，后续收到的SYN包，不进入SYN队列
-
计算出一个cookie值，再以SYN+ACK中的序列号返回客户端
-
服务端收到ACK之后，检查其合法性，合法直接压入Accept队列
-
应用程序调用accept() socket接口，从Accept队列中取出连接
-
-
-
增大半连接队列
-
减少 SYN+ACK 重传次数
DDos攻击
分布式拒绝服务（Distributed Denial of Service，简称DDoS）将多台计算机联合起来作为攻击平台，通过远程连接利用恶意程序，对一个或多个目标发起DDoS攻击，消耗目标服务器性能或网络带宽，从而造成服务器无法正常地提供服
原理：通常，攻击者使用一个非法账号将DDoS主控程序安装在一台计算机上，并在网络上的多台计算机上安装代理程序。在所设定的时间内，主控程序与大量代理程序进行通讯，代理程序收到指令时对目标发动攻击，主控程序甚至能在几秒钟内激活成百上千次代理程序的运行
1561
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
