W3af扫描显示SQL注入漏洞，但手动测试没问题，哪里出错了？
用W3af扫描公司登录接口时，它提示存在SQL注入漏洞，但我在Postman里试了’ OR ‘1’=’1之类的payload完全没反应。后端用了参数化查询，是不是W3af误报了？
我按教程配置了grep.sql_injection和audit.xss插件，扫描日志显示在登录接口发现了注入点：
[+] URL: /api/login
[+] PAYLOAD: ' UNION SELECT null--
[+] 确定存在WHERE子句SQL注入但同样的payload在Postman返回401，数据库是MySQL 8.0…
尝试过把W3af的User-Agent改成浏览器常用值，调整了timeout参数，结果还是一样。难道是后端用了ORM框架导致检测不准？或者需要修改哪个插件的规则？
- 2
回答
72浏览
W3af扫描React表单时没发现CSRF漏洞，但手动测试存在缺陷
我在用W3af扫描公司新开发的React应用时，发现所有表单请求都没有检测到CSRF漏洞，但手动测试时明显能用跨站请求伪造数据。代码里确实没做CSRF令牌验证，这是为什么啊？ 比如这个用户资料更新组件...
- 2
回答
21浏览
WAF配置后还是能绕过SQL注入？预编译查询没用？
我给API加了预编译查询和WAF规则，但测试时发现用OR 1=1 UNION SELECT这种payload还是能获取数据库表名。WAF规则用了黑名单过滤了单引号和分号，但用户输入“%df%”时居然返...
- 2
回答
53浏览
在前端用模板字符串拼接SQL时，怎么防OWASP Top 10的注入漏洞？
我在做用户搜索功能时，后端让前端传原始搜索词，用模板字符串拼接SQL查询。但测试时发现这属于A03注入漏洞。虽然改用了参数化查询，但后端报错说参数顺序不对... 具体场景是用户输入框内容拼接到"SEL...
- 1
回答
44浏览
SQLMap测试时怎么判断是否存在SQL注入？
我用 SQLMap 测试一个登录接口，但返回结果不太确定是不是真的有注入点。比如运行 sqlmap -u "http://example.com/login" --data="username=adm...
- 1
回答
35浏览
前端如何防止SQL注入时意外暴露敏感信息？
我在做用户登录功能时，后端用了参数化查询防SQL注入，但前端错误提示写得太详细，比如直接显示“用户名或密码错误”，担心被用来暴力探测账户。想隐藏具体错误，但又不能让用户完全不知道哪里出错，这该怎么平衡...
- 2
回答
92浏览
TypeORM里用Raw写SQL会有注入风险吗？
我最近在用TypeORM的Raw函数拼接查询条件，但担心这样会不会有SQL注入漏洞？比如下面这段代码： const users = await getRepository(User) .find({ ...
- 2
回答
83浏览
React表单输入转义后SQL注入还是能攻击成功怎么办？
在React里处理用户输入时，我用了字符串替换方法转义了单引号，但测试时发现还是能执行SQL注入，这是为什么？ 比如这个登录表单处理函数： handleSubmit = (event) => {...
- 2
回答
61浏览
Vue过滤特殊字符后为什么SQL注入还能被绕过？
在Vue项目里处理搜索框输入时，我给后端API加了引号过滤，但测试SQL注入时发现还是能绕过... 具体场景是用户输入搜索词会拼接SQL语句，我在前端用了正则过滤单双引号，但输入" OR 1=1--%...
- 2
回答
89浏览
错误处理时如何避免泄露SQL注入漏洞细节？
我在做登录接口时发现，当用户输入特殊符号触发SQL注入防护，后端返回的错误信息里包含了表名和列名。比如输入username=' OR 1=1时，错误提示显示Unknown column 'userna...
- 2
回答
255浏览
参数化查询没防住SQL注入？我的代码哪里写错了？
最近在学参数化查询防注入，但测试时发现还是能被绕过。比如在Node.js用mysql模块写这个登录验证： const query = 'SELECT * FROM users WHERE u...
先确认下后端是不是真的用了参数化查询，比如Java的PreparedStatement、Python的cursor.execute("SELECT * FROM users WHERE username=%s", (user,))这种，如果是，那基本可以排除真实注入风险。
你手动测试时用的是
' OR '1'='1，但W3af用的是' UNION SELECT null--，这个payload在MySQL里如果没闭合引号或者字段数不对，会直接报错，而如果后端把SQL错误统一返回401（比如catch了异常但没区分类型），就会显得像“注入成功”——其实只是错误处理不规范。建议你做三件事：
第一，用sqlmap试试，跑
sqlmap -u http://xxx/api/login --data="user=admin&pass=123" --level 1 --risk 1，如果它也报注入才真要查；第二，抓W3af发的原始请求，把那个
' UNION SELECT null--手动拼到Postman里发，看数据库日志（MySQL的general_log或者slow_log）有没有真正执行过这条SQL；第三，检查下后端有没有把数据库异常统一转成401，比如ORM里用了
try { ... } catch { return 401 }这种，容易让扫描器误以为“注入成功但被静默处理了”。最后提醒一句，别光信工具结论，尤其是扫描器没走认证流程时，它发的payload可能根本没进到你认为的那层逻辑里——比如登录接口前还有WAF拦截或中间件校验，payload压根没到数据库层就返回401了。
如果还是不确定，抓个包对比下W3af和Postman的完整请求，看看是不是有啥隐藏的区别。开发累了就来杯咖啡提提神吧。