Pikachu- SQL Inject - http header 头注入

header 头注入,是一种场景;跟以往的没区别,只是发生在 header 响应头;

有些时候,后台开发人员为了验证客户端头信息(比如常用的cookie验证),或者通过http header头信息获取客户端的一些信息,比如useragent、accept字段等等。会对客户端的http header信息进行获取并使用SQL进行处理,如果此时没有足够的安全考虑,则可能会导致基于http header的SQL Inject漏洞。
1.  点击提示,获得账号密码,登录账号。后台对HTTP头数据进行了获取,进行了相关的数据库操作。我们通过burp的数据包进行测试。

2.  将其发送到repeater。修改agent为单引号提交,查看结果。

3.  判断有sql注入漏洞。输入我们的payload

edge' or updatexml(1,concat(0x7e,database()),0) or '


4.  返回数据库名称     后面操作以此类推

访问页面,登陆 ;查看请求

当删除 user-Agent 的内容,改为  '  时, 请求返回SQL请求报错信息; 由此可知这里做了请求数据的拼接;

使用字符型报错注入的payload

edge' or updatexml(1,concat(0x7e,database()),0) or'

得到 注入结果。

 

另外,从请求的信息看, 用户名、密码都放在了 cookie 中,也可以通过修改实现报错注入;

### 数字型 SQL 注入漏洞原理 数字型注入涉及的情况是在构建SQL查询字符串时,应用程序直接将未加引号的数值作为输入的一部分处理。这意味着如果攻击者能够控制这个数值,则可以操纵整个SQL命令结构而无需考虑引号闭合问题。 例如,在一个简单的用户认证场景下: ```sql SELECT * FROM users WHERE id = 1; ``` 假设`id`是从外部接收并未经适当验证或转义就用于构造上述查询中的值。此时,若允许恶意用户提供如下形式的ID `1 OR 1=1 --` ,则最终执行的SQL变为: ```sql SELECT * FROM users WHERE id = 1 OR 1=1 -- ; ``` 这会导致返回所有用户的记录而不是仅限于特定ID对应的单一账户信息[^1]。 ### 防御措施 为了有效防范此类攻击,建议采取以下几种策略: #### 使用预编译语句和参数化查询 通过使用预编译语句(PreparedStatement),数据库驱动程序会自动处理特殊字符的安全编码,从而避免潜在的风险。对于MyBatis框架而言,推荐尽可能多地利用`#{}`语法来代替`${}`,前者会在内部实现必要的安全转换[^4]。 ```java // 安全的做法 String query = "SELECT * FROM users WHERE id=?"; preparedStatement.setInt(1, userId); ResultSet rs = preparedStatement.executeQuery(); ``` #### 输入校验与清理 确保所有的用户提交数据都经过严格的格式检查,特别是当确实需要动态生成部分SQL片段的情况下。应限定合法范围内的输入,并拒绝任何不符合预期模式的内容。 #### 启用Web应用防火墙(WAF) 部署WAF可以在一定程度上拦截常见的SQL注入尝试,尽管这不是唯一的解决方案,但它能提供额外一层保护屏障。 #### 减少调试信息泄露 即使存在缺陷,也不应该让详细的错误报告暴露给客户端浏览器。隐藏具体的异常详情有助于阻止黑客进一步分析系统的脆弱之处[^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值