secskill
  • Introduction
  • 1.web应用漏洞
    • 1.1 SQL注入漏洞
      • 1.1.1 type注入利用
      • 1.1.2 mothod注入利用
      • 1.1.3 按照效果注入利用
      • 1.1.4 order,limit和from后的注入
      • 1.10.1 sqlmap使用
    • 1.2 目录遍历漏洞
    • 1.3 跨站脚本漏洞
      • 1.3.10 flash xss
      • 1.3.11 Uxss
    • 1.4 未过滤HTML代码漏洞
    • 1.5 数据库运行出错
    • 1.6 Flash安全配置缺陷漏洞
    • 1.7 编辑器漏洞
      • 1.7.1 kindeditor编辑器漏洞
        • 1.7.1.1 kindeditor<=4.1.5文件上传漏洞
      • 1.7.2 fckeditor编辑器漏洞
        • 1.7.2.1 fckeditor<=2.6.4文件上传漏洞
    • 1.8 URL Redirect漏洞
    • 1.9 任意文件上传漏洞
    • 1.10 敏感信息泄露漏洞
    • 1.11 未加密登陆请求漏洞
    • 1.12 后台弱口令漏洞
    • 1.13 后台口令暴力破解漏洞
    • 1.14 跨站请求伪造漏洞
    • 1.15 Unicode 编码转换漏洞
    • 1.16 Possible .Net Error Message
    • 1.17 发生内部错误漏洞
    • 1.18 旁站攻击漏洞
    • 1.19 后台登录页面绕过
    • 1.20 Possible PHP Error Message
    • 1.21 UrlPath Pollution
    • 1.22 File Operation-Web.xml漏洞
    • 1.23 短文件名泄漏漏洞
    • 1.24 OS注入漏洞
    • 1.25 SOAP注入漏洞
    • 1.26 SMTP注入漏洞
    • 1.27 LDAP注入漏洞
    • 1.28 命令执行漏洞
    • 1.29 HTTP消息头注入漏洞
    • 1.30 验证机制缺陷漏洞
    • 1.31 越权漏洞
    • 1.31 服务端请求伪造漏洞
    • 1.32 xxe漏洞
    • 1.33 逻辑漏洞
    • 1.34 支付漏洞
      • 1.34.1 支付漏洞
    • 1.35 cors漏洞
      • 1.35.1 cors
    • 1.36 jsonp漏洞
    • 1.37 点击劫持漏洞
    • 1.38 框架注入漏洞
    • 1.39 文件包含漏洞
    • 1.40 CRLF注入漏洞
    • 1.41 SSTI漏洞
  • 2.中间件漏洞
    • 2.1 IIS
      • 2.1.1 CVE-2017-7269
    • 2.2 Apache
    • 2.3 Axis2
    • 2.4 lighttpd
    • 2.5 Tomcat
      • 2.5.1 CVE-2017-12615
    • 2.6 Nginx
    • 2.7 WebLogic
    • 2.8 JBoss
    • 2.9 Websphere
    • 2.10 Struct2
    • 2.11 XAMMP
    • 2.12 LAMPP
    • 2.13 FastCGI
    • 2.14 PHPCGI
    • 2.15 JOnAS
    • 2.16 Joomla
      • 2.16.1 CVE-2017-8917
    • 2.17 Padding oracle
    • 2.18 Jenkins
      • 2.18.1 CVE-2019-1003000
      • 2.18.2 CVE-2017-1000353
    • 2.18 Drupal
      • 2.18.1 CVE-2019-6340l
    • 2.19 PHPGD
      • 2.19.1 CVE-2019-6977
    • 2.20 PhpMyAdmin
      • 2.20.1 CVE-2016-5734
      • 2.20.2 反序列化漏洞
      • 2.20.3 CVE-2018-12613
    • 2.21 PHP
      • 2.21.1 extract
      • 2.21.2 strcmp
      • 2.21.3 urldecode
      • 2.21.4 md5
      • 2.21.5 strpos
      • 2.21.6 is_numeric
      • 2.21.7 sha
      • 2.21.7 ereg
      • 2.21.8 creat
  • 3.系统漏洞
    • 3.1 DNS域传送漏洞
    • 3.2 SSH Services Port 22 Enabled
    • 3.3 NetBIOS Services Port 139 Enabled
    • 3.4 OpenSSL 漏洞
    • 3.5 docker remote API漏洞
    • 3.6 Samba远程代码执行漏洞
    • 3.7 Windows系统漏洞
      • 3.7.1 ms17-010
      • 3.7.2 ms08-067
      • 3.7.3 ms16-075
      • 3.7.4 CVE-2017-0213
      • 3.7.5 ms16-135
      • 3.7.6 CVE-2018-8120
      • 3.7.7 CVE-2018-0824
    • 3.8 linux系统漏洞
      • 3.8.1 ubuntu
        • 3.8.1.1 CVE-2015-1328
        • 3.8.1.2 CVE-2017-16995
    • 3.9 openssh漏洞
      • 3.9.1 cve-2016-6515
  • 4.网络漏洞
    • 4.1 ARP欺骗嗅探漏洞
    • 4.2 反弹shell的N种姿势
    • 4.3 DNS欺骗
  • 5.cms漏洞
    • 5.1 08cms
    • 5.2 74cms
    • 5.3 Appcms
    • 5.4 Aspcms
    • 5.5 Bluecms
    • 5.6 Cscms
    • 5.7 Dedecms
    • 5.8 Discuz
      • 5.8.1 Discuz任意文件删除
    • 5.9 Dkcms
    • 5.10 Ecshop
    • 5.11 Finecms
    • 5.12 Fscms
    • 5.13 Jeecms
    • 5.14 Ibcms
    • 5.15 Maccms
    • 5.16 Php168
    • 5.17 Phpcms
    • 5.18 Phpmywind
    • 5.19 Phpwind
    • 5.20 Phpweb
    • 5.21 Qibocms
    • 5.22 Seacms
    • 5.23 Shopex
    • 5.24 Thinkphp
      • 5.24.1 SQL
      • 5.24.2 RCE
      • 5.24.3 RCE2
    • 5.25 Typecho
    • 5.26 Wordpress
      • 5.26.1 Wordpress Plugin_sql
    • 5.27 Xycms
    • 5.28 Zabbix
    • 5.29 Zblog
    • 5.30 Zzcms
Powered by GitBook
On this page
  • 漏洞描述
  • 漏洞等级
  • 漏洞危害
  • 漏洞检测方法
  • 漏洞利用方法
  • 漏洞修复方案
  • 漏洞案例

Was this helpful?

  1. 1.web应用漏洞

1.1 SQL注入漏洞

Previous1.web应用漏洞Next1.1.1 type注入利用

Last updated 6 years ago

Was this helpful?

SQL注入漏洞可以说是已经是一个历史漏洞了,早在15年的阿里峰会上,长亭科技的陈宇森就进行了名为《永别了SQL注入》的演讲,但作为最常见也是大家接触最多的漏洞,我们还是决定写出来,供大家学习。

漏洞描述

SQL注入是网站存在最多也是最简单的漏洞,主要原因是程序员在设计程序时,忽略了对输入字符串中夹带的SQL指令的检查,被数据库误认为是正常的SQL指令而运行,从而使数据库受到攻击,可能导致数据被窃取、更改、删除,以及进一步导致网站被嵌入恶意代码、被植入后门程序等危害。

我们一般的进行网站访问可以称为正常的web端口访问

SQL注入是如何访问?

(1)SQL注入也是正常的web端口访问

(2)只是传入的参数值并非是程序设计者所希望的,而是传入了嵌套SQL代码的参数值

(3)参数值利用程序处理注入者的逻辑,按注入者的期望执行数据库查询

(4)甚至页面呈现按SQL注入者期望显示

通常情况下,SQL注入的位置包括

  • 表单提交,主要是POST请求,也包括GET请求;

  • URL参数提交,主要为GET请求参数;

  • Cookie参数提交;

  • HTTP请求头部的一些可修改的值,比如Referer、User_Agent等;

  • 一些边缘的输入点,比如.mp3文件的一些文件信息等。

  • ……

漏洞等级

高危

漏洞危害

SQL注入的危害不仅体现在数据库层面上,还有可能危及承载数据库的操作系统;如果SQL注入被用来挂马,还可能用来传播恶意软件等,这些危害包括但不局限于:

(1)数据库信息泄漏:数据库中存放的用户的隐私信息的泄露。作为数据的存储中心,数据库里往往保存着各类的隐私信息,SQL注入攻击能导致这些隐私信息透明于攻击者。

(2)网页篡改:通过操作数据库对特定网页进行篡改。

(3)网站被挂马,传播恶意软件:修改数据库一些字段的值,嵌入网马链接,进行挂马攻击。

(4)数据库被恶意操作:数据库服务器被攻击,数据库的系统管理员帐户被篡改。

(5)服务器被远程控制,被安装后门。经由数据库服务器提供的操作系统支持,让黑客得以修改或控制操作系统。

(6)破坏硬盘数据,瘫痪全系统。

漏洞检测方法

可以使用:

%5c,单引号,双引号,反斜杠,负数, 特殊字符,and,or,xor探测是否存在注 入!

注释符# ­­+交替用,一个不行,就另一个 (一定要在注释符号后加空格,或者URL编码后的空格(%20),否则注释符号 不会产生作用)

1、先判断是数字型还是字符型,如果判断不出来跳到9

2、接着判断有没有括号

3、后面跟上­­+注释符

4、order by判断字段数,如果没法判断,则直接union select 1,2,3一个个测试过去

5、如果返回的页面发生变化,则联合查询

6、如果union select 1,version(),3返回的页面没有发生变化,即联合查询失败,则尝试报错 注入

7、如果报错注入页面也没有把信息显示出来,则延时注入

8、如果延时注入也不行,则导入导出

9、尝试延时注入,如果从1过来的,则三种情况,直接跟payload,参数后面加单引号或者 双引号

漏洞利用方法

注入点分类:

按照注入点类型来分类

(1)数字型注入点

(2)字符型注入点

闭合单引号chr='admin' union select 1,2,3,4 and '1'='1 ====> chr='admin'(闭合前面单引号) union select 1,2,3,4 and '1'='1'

(3)搜索型注入点

这是一类特殊的注入类型。这类注入主要是指在进行数据搜索时没过滤搜索参数,一般在链接地址中有“keyword=关键字”,有的不显示在的链接地址里面,而是直接通过搜索框表单提交。此类注入点提交的 SQL 语句,其原形大致为:select * from 表名 where 字段 like '%关键字%'。

组合出来的sql注入语句为:select * from news where search like '%测试 %' and '%1%'='%1%'

测试%' union select 1,2,3,4 and '%'='

按照数据提交的方式来分类 (1)GET 注入

(2)POST 注入

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

(3)Cookie 注入

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

(4)HTTP 头部注入

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

按照执行效果来分类

(1)基于布尔的盲注,即可以根据返回页面判断条件真假的注入。

(2)基于时间的盲注,即不能根据页面返回内容判断任何信息,用条件语句查看时间延迟语句是否执行(即页面返回时间是否增加)来判断。

(3)基于报错注入,即页面会返回错误信息,或者把注入的语句的结果直接返回在页面中。

(4)联合查询注入,可以使用union的情况下的注入。

(5)堆查询注入,可以同时执行多条语句的执行时的注入。

下文将会对这些知识点进行简单介绍,并对并穿插以下waf绕过姿势等

漏洞修复方案

解决SQL注入问题的关键是对所有可能来自用户输入的数据进行严格的检查、对数据库配置使用最小权限原则。 通常使用的方案有:

(1)所有的查询语句都使用数据库提供的参数化查询接口,参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。当前几乎所有的数据库系统都提供了参数化SQL语句执行接口,使用此接口可以非常有效的防止SQL注入攻击。

(2)对进入数据库的特殊字符('"\<>&*;等)进行转义处理,或编码转换。

(3)确认每种数据的类型,比如数字型的数据就必须是数字,数据库中的存储字段必须对应为int型。

(4)数据长度应该严格规定,能在一定程度上防止比较长的SQL注入语句无法正确执行。

(5)网站每个数据层的编码统一,建议全部使用UTF-8编码,上下层编码不一致有可能导致一些过滤模型被绕过。

(6)严格限制网站用户的数据库的操作权限,给此用户提供仅仅能够满足其工作的权限,从而最大限度的减少注入攻击对数据库的危害。

(7)避免网站显示SQL错误信息,比如类型错误、字段不匹配等,防止攻击者利用这些错误信息进行一些判断。

(8)在网站发布之前建议使用一些专业的SQL注入检测工具进行检测,及时修补这些SQL注入漏洞。

漏洞案例

  • 网络安全实验室注入关

  • sqlilabs

  • btslab

  • webug

  • webgoa

  • Owasp Broken Web Application Project

在 Web 端大概是 这种形式,其注入点 id 类型为数字,所以叫数字型注入点。这一类的 SQL 语句原型大概为 select from 表名 where id=1。组合出来的sql注入语句为:select from news where id=1 and 1=1

在 Web 端大概是 这种形式,其注入点 name 类型为字符类型,所以叫字符型注入点。这一类的 SQL 语句原型大概为 select from 表名 where name='admin'。注意多了引号。组合出来的sql注入语句为:select from news where chr='admin' and 1=1 ' '

提交数据的方式是 GET , 注入点的位置在 GET 参数部分。比如有这样的一个链接 , id 是注入点。

http://xxx.com/news.php?id=1
http://xxx.com/news.php?name=admin
http://xxx.com/news.php?id=1
永别了SQL注入