超简单的Sql注入之万能密码

嘿，我听说过你之前提到的这个通用密码。
这种脆弱性在入口处尤其危险。
例如，如果一个网站的后端没有验证用户输入的数据，那么人们就可以利用这个漏洞进行登录。

2 01 8 年早些时候，我在一个论坛上看到过这样的事情。
有网友说，他使用通用密码成功进入了一个网站的后端，当时觉得很神奇。
通用密码和你说的一样。
例如输入“admin'或1 =1 ”，然后就可以绕过正常的验证机制，直接登录。

此类漏洞主要是因为网站的数据库查询语句没有经过很好的过滤，使得黑客可以通过在输入框中输入特殊字符来改变SQL查询语句的逻辑。
正如你所说，黑客会在用户名后面添加“'或1 =1 ”，因此无论输入什么用户名，尾随条件“1 =1 ”都会被执行。
这显然总是正确的，因此您可以登录。

不过，现在很多网站都加强了对SQL注入的防御，比如使用预编译语句、参数化查询等，可以有效防止这种万能密码攻击。
但归根结底，网站开发者必须重视安全性，不能仅依靠用户来防范此类漏洞。
上次有客户问我，他们公司的网站被黑了，所以我建议他们加强数据库安全，防止此类漏洞被利用。
反正照顾好就好，安全没什么大不了的。

【DVWA实战篇】12分钟学会 SQL 注入攻击实战

SQL注入利用未经验证的输入直接拼接成SQL命令，使得服务器能够恶意执行命令。

分为普通注射和盲注。
一般来说，当投注接受盲目判断时，结果是直接查看的。

分为数字和字符。
每列中都包含类型字符并进行注释。
通过 GET 和 POST 提交。

下层战斗本身的记录： 安全性低，提交。
输入1 '报错，该错误为MySQL漏洞。
使用 and 1 =1 /2 进行测试，字符类型。
当'且1 =2 时注入成功。
使用 orderby 来测试字段数量。
使用联合数据库 select() 获取 dvwa 数据库名称。
使用 union select 1 , group_concat(table_name) from information_schema。
表，其中 table_schema=database() 获取表的名称。
使用 union select 1 , group_concat(column_name) from information_schema.columns where table_name='users users users get 字段。
使用共享用户选择、用户密码来获取用户的密码。
一个实用的低级SQLMap自动化工具： Kali 接受 DVWA 配件和 cookie。
SQLMap自动检测数据库名称、表名称、字段名称和用户密码。

实际中战进展： 提交后，介质是安全的。
使用 Burpsuite 构建包后。
添加“一个数字”来查找漏洞。
加和 1 =1 /2 测试，数字类型。
添加联合选择方法来识别表结构和字段。
发现函数 mysql_real_escape_string 且构造失败。
使用不带单独逗号的十六进制 HEX 编码方法来标识字段名称。
我正在寻找用户密码。
实用的中级SQLMap自动化工具： Burpsuite 拦截 POST 文件并将其转录到 SQLMap。
SQLMap 要求提供数据库名称、表名称和字段名称。
已识别用户密码。

关于此事的争论： 高安全性，符合 POST 标准。
输入单句字符时，会返回错误。
数据库类型未知。
评论TERMINAL 1 命令、发送数据、字符类型漏洞。
后续步骤与下面的步骤相同。

实际竞争不可能达到的水平： 不可能的安全，PDO技术。
PDO将SQL语句和变量分开以防止注入。

PDO的抗注射效果最好。

SQL注入的常见攻击方式和案例分析

坦率地说，SQL注入的目的是通过创建恶意SQL语句来操纵数据库。
这很复杂，因为它可以通过多种方式受到攻击。
我们先来说说最重要的事情。
注入盒注入是一种常见的攻击方式。
例如，在我们去年实施的项目中，我们遇到了登录框条目的问题，影响了大约3 000名用户。
还有一点，URL参数注入也很常见，比如搜索功能。
去年我们修复了由于输入 URL 参数而导致的数据泄露问题。
另一个关键细节是盲注入，包括逻辑盲注入和时间盲注入。
这些依赖于监视页面的响应来推断 SQL 语句是真还是假，或者延迟响应来确定条件是否为真。

一开始我以为SQL注入只是一个小问题，后来发现是一个错误。
它可能会导致严重的数据泄露。
等等，还有其他的东西，比如 2 009 年的 Twitter 和 2 01 2 年的 Yahoo！所有投票数据泄露都是由 SQL 注入漏洞造成的。

就预防措施而言，首先参数化查询（预编译数据）是关键。
我们的项目去年就采用了这种方法，大大降低了注入的风险。
此外，ORM工具还可以自动生成参数化SQL，降低手动代码绑定的风险。
还有最小特权原则。
例如，我们限制数据库帐户只能执行特定的存储过程，这样即使输入了也很难执行高风险操作。
定期更新和补丁也很重要。
例如，2 02 1 年的Log4 j漏洞就是由于未能及时更新补丁而导致的。
最后，输入验证、过滤和 Web 应用程序防火墙 (WAF) 也是有效的防御措施。

我认为尝试将技术防护与管理流程结合起来，例如代码审查、安全培训等，构建长期防御体系是有用的。
通过了解攻击原理、分析历史案例、实施全面的防范措施，可以显着降低SQL注入风险，保障数据安全。