本文探讨了CERT-J建议的输入验证和数据净化以防止SQL注入，提供了解决方案如使用PreparedStatement。同时，文章提醒在面向对象编程中避免返回私有可变成员对象的引用，以保护类的私有状态。举例说明了Date对象的可变性问题，并建议使用clone方法来避免意外修改。
1.CERT-J输入验证和数据净化，需要解决sql注入问题
SQL注入漏洞的出现是因为生成的SQL查询语句部分元素来自非受信源。在没有防范的情况下，来自非受信源的数据可能恶意串改SQL查询语句，导致了信息的泄露和数据的更改.
假设一个系统对用户进行身份验证，通过如下查询语句访问SQL数据库。如果查询返回任何结果，则验证成功，否则，身份验证失败。
SELECT * FROM db_user WHERE username=‘’ AND password=‘’
假设攻击者可以把<用户名>和<密码>替换为任意字符串。在这种情况下，为用户名输入下列字符串而密码输入任意值就可以顺利绕过身份验证机制：
validuser’or‘1’= ‘1
鉴权用户的查询语句拼接如下：
SELECT * FROM db_user WHERE username=‘validuser’ OR ‘1’=‘1’ AND password=‘’
如果validuser记录在数据库表中存在，是一个有效的用户名，查询语句停止继续检查其他条件，不需要验证密码部分，因为用户名 validuser 判定结果是True,所有or 后面的部分不需要继续进行判定，但需要保证OR后面的SQL表达式语法正确，这样攻击者就取得了 validuser 用户的权限。类似的，攻击方可以通过构造如下密码和任意的用户名。
’ OR ‘1’='1
查询语句拼接后如下：
SELECT * FROM db_user WHERE username=‘’ AND password=‘’ OR ‘1’=‘1’
‘1’='1判定结果
最低0.47元/天 解锁文章
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
