一、sql注入

产生原因：

刚刚讲过当我们访问动态网页时, Web 服务器会向数据访问层发起 Sql 查询请求，如果权限验证通过就会执行 Sql 语句。

这种网站内部直接发送的Sql请求一般不会有危险，但实际情况是很多时候需要结合用户的输入数据动态构造 Sql 语句，如果用户输入的数据被构造成恶意 Sql 代码，Web 应用又未对动态构造的 Sql 语句使用的参数进行审查，则会带来意想不到的危险。

威胁：

1、猜解数据库，盗取数据库信息。

2、绕过验证，直接登录网站后台。

3、如果网站目录存在写入权限，可以写入网页木马。

4、提权

分类：

1、按注入点类型分：


数字型


这一类的 SQL 语句原型大概为 select * from 表名 where id=1

可以构造　select * from 表名 where id=1 and 1=1 一类的语句


字符型


这一类的 SQL 语句原型大概为 select * from 表名 where id=‘1’ （单引号双引号都有可能）

可以构造　select * from 表名 where id=‘1’ and 1=1 #’ 一类的语句 (#用于忽略最后的 ’ )

也有　select * from users where username=‘1’ or ‘1’=‘1’ and password=‘1’ or ‘1’=‘1’

2、按照提交数据来分类：


GET 注入


提交数据的方式是 GET , 注入点的位置在 GET 参数部分。比如有这样的一个链接http://xxx.com/news.php?id=1 , id 是注入点。


POST 注入


使用 POST 方式提交数据，注入点位置在 POST 数据部分，常发生在表单中。


Cookie 注入


HTTP 请求的时候会带上客户端的 Cookie, 注入点存在 Cookie 当中的某个字段中。


HTTP 头部注入


注入点在 HTTP 请求头部的某个字段中。比如存在 User-Agent 字段中。严格讲的话，Cookie 其实应该也是算头部注入的一种形式。因为在 HTTP 请求的时候，Cookie 是头部的一个字段。

3、按照执行效果来分类：


基于布尔的盲注


根据返回页面判断条件真假的注入。


基于时间的盲注


能根据页面返回内容判断任何信息，用条件语句查看时间延迟语句是否执行（即页面返回时间是否增加）来判断。


基于报错注入


页面会返回错误信息，或者把注入的语句的结果直接返回在页面中。

getshell

1.写文件–into outfile


前提：

web目录具有写权限，能够使用单引号

知道网站绝对路径（根目录，或则是根目录往下的目录都行）

secure_file_priv没有具体值（（secure_file_priv是用来限制load dumpfile、into outfile、load_file()函数在哪个目录下拥有上传和读取文件的权限。在mysql 5.6.34版本以后 secure_file_priv的值默认为NULL。）

payload：

union select 1,2,3,'<?php @eval($_REQUEST[cmd])?>' into dumpfile 'E:/wamp/www/shell.php‘
　?name=1'UNION SELECT 1,<?php eval($_POST['cmd']); ?> into outfile 'D:\\Phpstudy\\WWW\\vul\\sqli\\shell.php' --+

2.–os-shell


原理：–os-shell就是使用udf提权获取WebShell。也是通过into oufile向服务器写入两个文件，一个可以直接执行系统命令，一个进行上传文件

前提：

要求为DBA数据库管理员权限（–is-dba：phpstudy搭建的一般为DBA）

php主动转义的功能关闭（PHP的GPC关闭），能使用单双引号（需要单引号路径，不能使用0x编码）

知道网站的绝对路径；文件不能覆盖写入，所以文件必须为不存在

–secure-file-priv没有值

使用方法：sqlmap -u “http://127.0.0.1/shell.php?name=1&submit=%E6%9F%A5%E8%AF%A2” -p name –os-shell（写入绝对路径）

sqlmap在指定的目录生成了两个文件（文件名是随机的，并不是固定的）：

– tmpbwswq.php 用来执行系统命令

– tmnmwvgw.php 用来上传文件

防御

1. 严格检查输入变量的类型和格式，对于整数参数，加判断条件：不能为空、参数类型必须为数字，对于字符串参数，可以使用正则表达式进行过滤：如：必须为[0-9a-zA-Z]范围内的字符串。

2.永远不要使用动态拼装sql，可以使用参数化的sql或者直接使用存储过程进行数据查询存取。

3.过滤和转义特殊字符, 在变量前进行转义，对’、”、\等特殊字符进行转义。

4.使用预编译，而其后注入的参数将不会再进行SQL编译。也就是说其后注入进来的参数系统将不会认为它会是一条SQL语句，而默认其是一个参数，参数中的or或者and 等就不是SQL语法保留字了。

二、CSRF漏洞

CSRF（Cross-site request forgery）跨站请求伪造，也被称为One Click Attack 或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常 不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击性往往不大流行（因此对其进行防范的资源也相对少）和难以防范，所以被认为比XSS更具危险性。

（CSRF与XSS最大的区别就在于，CSRF并没有盗取cookie而是直接利用）

威胁

以受害者的名义发送邮件、发消息、盗取受害者的账号，甚至购买商品、虚拟货币转账、修改受害者的网络配置（比如修改路由器DNS、重置路由器密码）等等操作。造成的问题包括：个人隐私的泄露、机密资料的泄露、用户甚至企业的财产安全；

类型

1.get请求型CSRF

只需要构造URL，然后诱导受害者访问利用。

2.POST请求型CSRF

构造自动提交的表单，诱导受惠者访问或者点击

原理

1.用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；

2.在用户信息用过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；

3.用户未退出网站A之前，在同一浏览器中打开一个TAB页访问网站B；

4.网站B接受到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；

5.浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

检测

1.是抓取一个正常请求的数据包，去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。

2.使用专门的CSRF漏洞检测工具，若CSRFTester，CSRF Request Builder等。

防御

1.验证HTTP Referer字段；

2.在请求地址中添加随机token并验证；

三、xss漏洞

XSS 攻击全称跨站脚本攻击，是为不和层叠样式表(Cascading Style Sheets, CSS) 的缩写混淆，故将跨站脚本攻击缩写为 XSS，XSS 是一种在 web 应用中的计算 机安全漏洞，它允许恶意 web 用户将代码植入到 web 网站里面，供给其它用户 访问，当用户访问到有恶意代码的网页就会产生 xss 攻击

原理

用户输入的内容被浏览器当作了前端代码进行执行

类型

1.反射型（非持续）：

通过web站点漏洞，向客户端交付恶意脚本代码，实现对客户端 的攻击。

攻击目标: web客户端

（主要是利用客户端浏览器来运行恶意脚本）

主要脚本语言： javascript

条件：

服务器对用户提交数据过滤不严格

web站点能够返回用户输入的 数据(脚本)

脚本在客户端执行恶意操作

2.存储型（持续）：攻击数据储存在对方服务器，持续攻击，危害程度较大

3.DOM：攻击数据作为前端js函数参数去执行，不与后端进行交互（前端语言进行处理）【很容易发现，可以直接看前端源代码得到，可以作为反射性的一种】

威胁

1.盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号

2.控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力

3.盗窃企业重要的具有商业价值的资料

4.非法转账

5.强制发送电子邮件（钓鱼）

6.网站挂马

7.控制受害者机器（肉鸡）向其它网站发起攻击

常见位置

URL、表单、搜索框、评论区、留言区、个人信息、订单信息等

站内信、网页即时通讯、私信、意见反馈搜索框、当前目录、图片属性等

防御

开启HttpOnly

使用 React JS、Ruby on Rails 和其他在很大程度上避免 XSS 设计的框架

避免 HTML 中不受信任的 HTTP 请求数据，除非在 OWASP 备忘单系列“XSS 预防”中定义的允许插槽中

在 HTML 元素中插入任何不受信任的数据之前使用 HTML 编码

对基于 DOM 的 XSS 应用上下文敏感编码

实施内容安全策略 (CSP)，为客户端资源创建源允许列表。如果没有允许通过本地文件插入恶意代码的漏洞，这将很有帮助

HttpOnly绕过

如果您在cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击。

(1) CVE-2012-0053

Apache服务器2.0-2.2版本存在个漏洞 CE-2012-0053:攻击者可通过向网站植人超大的Cookie,令其HTTP头超过Apache的LititRequestFieldSize (最大请求长度，4192字节)，使得Apache返回400错误，状态页中包含了HttpOnly 保护的Cookie。源代码可参见: htps:/ww.explwi db.com/exploits/18442/。

除了Apache，-些其他的 Web服务器在使用者不了解其特性的情况下，也很容易出现HttpOnly保护的Cookie被爆出的情况，例如Squid等。

(2) phpinfo

无论是否设置了HttpOnly 属性，phpinfo()函数都会输出当前请求上下文的Cookie信息。如果目标网站存在phpinfo页面，就可以通过XMLHttpRequest请求该页面获取Cookie信息。

(3) Flash/Java

安全团队seckb在2012年提出，通过Flash、Java 的一些API可以获取到HttpOnly Cookie,

这种情况可以归结为客户端的信息泄露，链接地址为: htp://ckb.yehg.net/2012/0/xss-gaining-g

aCss-t-ttponly-cookie.html。