如何防止“DROP BOBBY TABLES”当用户输入带有特殊字符的密码时?
在我们古老的经典 ASP 环境中,我们利用 OWASP 从请求对象获取密码并对非字母数字字符进行加密。这是防止sql注入的第一道防线。我们使用其他方法来全面预防 SQL 注入。
问题是,当我们收集数据以组合 HTTP post 消息并从用户输入中获取密码时,对其进行 OWASP 并将其发送。因此密码不正确。
示例:密码 freddie$cougar 变为 freddie&36;cougar
我们最终所做的是假设 50 个字符的文本字段没有足够的空间来执行大量 SQL 注入,并更改了代码,因此我们没有 OWASP 传入的密码。感觉有点害怕。
他们有更好的方法吗?
代码是用 vbScript 编写的。
In our ancient Classic ASP environment, we utilize OWASP to get the password from the request object and encrypt non-alphanumeric characters. This is a first line of defense to preventing sql injection. We use other methods for full sql injection prevention.
The problem is, when we are collecting data to put together an HTTP post message and just grab the password from the user input, OWASP it and send it along. The password is therefore incorrect.
Example: Password freddie$cougar becomes freddie&36;cougar
What we ended up doing was assuming that a 50 character text field was not enough space to do much sql injection and changed the code so we didn't OWASP the password coming in. This feels a bit scary.
Is their a better way?
The code is written in vbScript.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
更好的解决方案是将所有查询转换为参数化查询。
这是 12 岁文章解释了如何操作:)
A better solution is to convert all queries to parameterized ones.
Here is a 12 year old article explaining how :)
为什么要以明文形式发送密码?计算密码的哈希值并发送该值。这将使您能够防止 SQL 注入并避免中间人类型的攻击。
无论如何,您还必须在数据到达服务器时清理数据。即使您的 vbscripts 执行客户端验证,通过绕过您的脚本并手工制作包含恶意输入的数据包来攻击您的服务也是微不足道的。
Why are you sending the password in clear text? Calculate a hash value for the password and send that one. This would allow you to prevent SQL injection and to avoid man-in-the-middle type attacks.
In any case, you have to also clean up the data as it comes to your server. Even if your vbscripts does client-side validation, it would be trivial to attack your service by bypassing your script and hand-crafting a packet with malicious input in it.
考虑将 SQL 语句移至存储过程,并确保不在这些存储过程中使用动态 SQL。
除此之外,最好不要将密码存储在数据库中,而是存储加盐哈希值。
无论您发送到数据库的字符串是什么,上面的方法都是首选,因为只要您不使用带有动态 SQL 的参数,它就会避免直接作为即席语句执行,并且会避免 SQL 注入存储过程。
Consider moving your SQL statements to stored procedures, and ensure that you don't use dynamic SQL within those stored procs.
Aside, it's definitely best to not even store the pwd in your database, but rather a salted hash.
The method above is preferred, no matter what string you're sending to your database, as it'll avoid executing directly as an adhoc statement, and will avoid SQL injection, as long as you're not using the parameter with dynamic SQL within the stored proc.
许多网站都限制密码中可以使用的字符集 - 选择一组不会给您带来麻烦的字符集。这可能意味着字母数字和一些标点符号(逗号、句号、破折号)。话虽如此,这些网站还是让我很恼火——只要有机会,我就会在密码中使用丰富的字符,而在仅包含字母数字的网站上,我通常最终会使用“IHateNoPunctSites”等无意义的内容作为密码。
将密码作为十六进制编码字符串或 Base-64 编码字符串发送怎么样?然后,您可以在末尾对字符串进行解码,并尽可能小心地防止任何注入,而不限制密码中使用的字符集。当您需要检查密码时,您可以确保使用参数化查询干净地完成此操作。或者,您可以在将查询发送到密码文件之前使用其盐对密码进行哈希处理。无论如何,您不应该对密码做太多事情。
A lot of sites limit the set of characters that can be used in passwords - choose a set that is not going to cause you grief. That probably means alphanumerics, and some punctuation (comma, full stop, dash). Having suggested that, those sites annoy me - I use a rich set of characters in my passwords when given the chance to do so, and on the alphanumeric-only sites I usually end up using nonsense like 'IHateNoPunctSites' as the password.
What about shipping the password as a hex-encoded string, or a base-64 encoded string? You can then decode the string at the end, being as careful as necessary to prevent any injection without limiting the character set that is used in the password. When you need to check the password, you can ensure you are doing it cleanly using a parameterized query. Or you can hash the password with its salt before sending the query off to the password file. You should not be doing much with passwords anyway.