赞
踩
(5)以下链接存在 SQL 注入漏洞,对于这个变形注入,你有什么思路:
(6)发现 demo.jsp?uid=110 注入点,你有哪几种思路获取 webshell,哪种是优选:
(11)mysql 的网站注入 5.0 以上和 5.0 以下有什么区别:
按数据的传递方式可以分为:get 注入、post 注入、cookie 注入
根据 注入点 类型分类:数字型、字符型
根据 执行效果 分类:有回显的注入、盲注、报错注入、堆叠注入、宽字节注入
盲注是在 SOL注入攻击过程中,服务器关闭了错误回显,我们单纯通过服务器返回内容的变化来判断是否存在 SOL注入和利用的方式
盲注的手段有两种:
(1)通过页面的返回内容是否正确(boolean-based),来验证是否存在注入;
(2)通过 SQL 语句处理时间的不同来判断是否存在注入(time-based),可以用benchmark,sleep 等造成延时效果的函数;
产生原理:
多字节字符集的使用:在多字节字符集中,如GBK,一个汉字可能由两个字节组成。这种编码方式允许将两个字节识别为一个字符.
转义函数的局限性:例如 PHP 中的 addslashes()
函数,它在特殊字符前添加反斜线(\
)以防止SQL注入。但当使用宽字节字符集时,转义函数可能无法正确处理所有字符,导致转义失效.
编码转换问题:在使用 PHP 连接MySQL数据库时,如果设置了特定的字符集(如GBK),在字符编码转换过程中,某些字节序列可能被错误地解释为单个字符,从而绕过了转义机制.
根本原因:
字符集不统一:应用程序和数据库系统之间使用不同的字符集,可能导致字符编码和解码过程中出现不一致,为宽字节注入提供了机会.
转义机制的缺陷:转义函数可能没有考虑到所有可能的字符编码情况,特别是在处理多字节字符集时,导致转义不彻底或错误.
安全措施不足:如果应用程序仅依赖于转义函数来防止SQL注入,而没有采取更全面的安全措施,如使用预处理语句或参数化查询,就可能存在安全漏洞
(1)绕过登录验证,比如说使用万能密码登录网站;
(2)获取网站管理员账号密码;
(3)读取文件、写入 webshell 等;
demo.do?DATA=AjAxNg==
DATA 有可能经过了 base64 编码再传入服务器,所以我们也要对参数进行 base64 编码才能正确完成测试.
有写入权限的,构造联合查询语句使用 using INTO OUTFILE,可以将查询的输出重定向到系统的文件中,这样去写入 WebShell 使用 sqlmap -os-shell 原理和上面一种相同,来直接获得一个 Shell,这样效率更高。
通过构造联合查询语句得到网站管理员的账户和密码,然后扫后台登录后台,再在后台通过改包上传等方法上传 Shell.
(1)如果是 get 型号,直接,sqImap -u "注入点网址"
(2)如果是 post 型注入点,可以 sqmap -u "注入点网址" --data="post 的参数"
(3)如果是 cookie,X-Forwarded-For 等,可以访问的时候,用 burpsuite 抓句,注入处用号替换,放到文件里,然后 sqlmap -r "文件地址"
-u (指定 url)
-r (读取需要注入的 post 请求的文本)
-m (批量跑 get 注入)
-p (指定注入参数)
-current-db: (获取当前数据库)
--table (枚举数据库表)
--tamper (使用过 waf 脚本)
(1)使用安全的 API
(2)对输入的特殊字符进行 Escape 转义处理.
(3)使用白名单来规范化输入验证方法.
(4)对客户端输入进行控制,不允许输入SQL注入相关的特殊字符.
(5)服务器端在提交数据库进行SQL查询之前,对特殊字符进行过滤、转义、替换、删除
(6)规范编码,字符集.
原理:
使用参数化查询数据库服务器 不会把参数的内容当作 SQL指令 来执行,是在数据库完成 SQL 指令的编译后才套用参数运行。
简单的说:
参数化能防注入的原因在于,语句是语句,参数是参数,参数的值并不是语句的一部分,数据库只按语句的语义跑。
5.0 以下没有 information_schema 这个系统表,无法列表名等,只能暴力跑表名;
5.0 以下是多用户单操作,5.0 以上是多用户多操作。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。