Open meishaoming opened 4 years ago
前端页面在渲染的时候，会执行 HTML 里的脚本。一般情况下，这些 <script> 标签的脚本由网站开发人员编写，是安全的。但如果我有办法在 HTML 里插入一段 js，而且 js 会在渲染时被执行，那么这个就可以做到 XSS 攻击了。
<script>
所以核心的问题是：如何网别人的网页里插入 js ？
例一：从数据库返回
假设某网站前端存在这种漏洞。用户在留言板输入 <script>alert(1)<script> 这样的留言，提交之后留言内容被后台存入数据库。之后方面这个页面时后台会从数据库里把留言取出返回给前端。前端在渲染界面时看到 <script>alert(1)<script> 语句就直接执行了。
<script>alert(1)<script>
实际攻击的时候会有更加复杂的脚本，常见的是把本地用户的 cookie 发送到某个服务器地址。这样攻击都就拿到用户的 cookie 。
还有一例 XSS实战：我是如何拿下你的百度账号 比较实战。
这种脚本被存到后台数据库里的攻击类型，称为「持久型XSS攻击」，也称为「存储型XSS攻击」。
例二：
比如在一个页面上，我们要执行一个搜索操作。在操作框输入关键字，这个输入内容会传到后台执行搜索，然后把搜索结果返回给前端页面。如果输入的关键字里带有 script 脚本，服务器又未加处理把这个信息返回给前端。页面渲染时就会执行这个脚本。
这种临时的 js 注入称为 非持久型XSS攻击，也称为 反射型XSS攻击，也就是从服务器反射到前端页面上。常见的攻击类型是诱导用户点击某个带参数的链接，链接的网站地址是安全的，但这个网站有漏洞，会把参数返回给前端页面然后被执行恶意 js 代码。
上面两例，不管持不持久，本质上是一样的，让前端执行注入的 js 脚本。
前端安全系列（二）：如何防止CSRF攻击？
例子：在用户输入的地方，如表单、搜索框，用户一般输入的都是关键字。但是如果用户输了了关键字后边还带 SQL 语句，后台收到之后直接把用户输入的数据拼接起来执行 SQL 操作，那么就会连带执行注入的 SQL 语句。这种漏洞可以用来获取到后台数据库的信息，甚至是恶意删表。
本质上是：未充分有效的检查用户输入数据，使得用户输入数据变成代码指令被执行。
防范：
XSS (Cross-Site Scripting) 跨站脚本攻击
前端页面在渲染的时候，会执行 HTML 里的脚本。一般情况下，这些
<script>标签的脚本由网站开发人员编写，是安全的。但如果我有办法在 HTML 里插入一段 js，而且 js 会在渲染时被执行，那么这个就可以做到 XSS 攻击了。所以核心的问题是：如何网别人的网页里插入 js ？
例一：从数据库返回
假设某网站前端存在这种漏洞。用户在留言板输入
<script>alert(1)<script>这样的留言，提交之后留言内容被后台存入数据库。之后方面这个页面时后台会从数据库里把留言取出返回给前端。前端在渲染界面时看到<script>alert(1)<script>语句就直接执行了。实际攻击的时候会有更加复杂的脚本，常见的是把本地用户的 cookie 发送到某个服务器地址。这样攻击都就拿到用户的 cookie 。
还有一例 XSS实战：我是如何拿下你的百度账号 比较实战。
这种脚本被存到后台数据库里的攻击类型，称为「持久型XSS攻击」，也称为「存储型XSS攻击」。
例二：
比如在一个页面上，我们要执行一个搜索操作。在操作框输入关键字，这个输入内容会传到后台执行搜索，然后把搜索结果返回给前端页面。如果输入的关键字里带有 script 脚本，服务器又未加处理把这个信息返回给前端。页面渲染时就会执行这个脚本。
这种临时的 js 注入称为 非持久型XSS攻击，也称为 反射型XSS攻击，也就是从服务器反射到前端页面上。常见的攻击类型是诱导用户点击某个带参数的链接，链接的网站地址是安全的，但这个网站有漏洞，会把参数返回给前端页面然后被执行恶意 js 代码。
上面两例，不管持不持久，本质上是一样的，让前端执行注入的 js 脚本。
CSRF (Cross-site request forgery) 跨站请求伪造
前端安全系列（二）：如何防止CSRF攻击？
SQL 注入
例子：在用户输入的地方，如表单、搜索框，用户一般输入的都是关键字。但是如果用户输了了关键字后边还带 SQL 语句，后台收到之后直接把用户输入的数据拼接起来执行 SQL 操作，那么就会连带执行注入的 SQL 语句。这种漏洞可以用来获取到后台数据库的信息，甚至是恶意删表。
本质上是：未充分有效的检查用户输入数据，使得用户输入数据变成代码指令被执行。
防范：