所以这意味着没有像$variable = $_POST [‘user_input’]这样的东西.对于这样的任何情况,您将过多的控制权移交给用户.如果输入影响某些数据库查询,则始终使用白名单来验证用户输入.如果查询是针对用户名,请根据良好用户名列表进行验证.不要简单地使用直接放入的用户输入进行查询.
一个(可能的)例外是搜索字符串.在这种情况下,您需要进行清理,就像那样简单.
>避免存放用户输入而不需要卫生设施.
如果用户正在为其他用户创建配置文件或上传信息,则必须具有可接受的数据类型的白名单,或者删除任何可能是恶意的数据.这不仅适用于您系统的安全性,也适用于您的其他用户(请参阅下一点.)
这可能是安全顾问向我强调的最重要的事情.当用户收到输入时,您不能简单地依赖于清理输入.如果您没有自己编写输出,请始终通过编码任何HTML字符或将其包装在< plaintext>中来确保输出无害.标签.如果用户A上传了一些损害查看该页面的任何其他用户的javascript,那么开发人员就会出于简单的疏忽.知道任何和所有用户输出除了在所有浏览器上显示为文本之外什么都不做,你会在晚上睡得更好.
>除了用户控制表单外,绝不允许任何人.
XSS比应该更容易,并且在一个段落中覆盖真正的痛苦.简而言之,无论何时创建表单,您都可以让用户访问将处理表单数据的脚本.如果我窃取某人的会话或某人的cookie,我现在可以与脚本交谈,就像我在表单页面上一样.我知道它所期望的数据类型以及它将寻找的变量名称.我可以简单地将那些变量传递给它,就像我是用户一样,脚本无法区分.
以上不是卫生问题,而是用户验证问题.我的最后一点与这个想法直接相关.
>避免使用cookie进行用户验证或角色验证.
如果我可以窃取用户的cookie,我可能做的不仅仅是让一个用户度过糟糕的一天.如果我注意到cookie有一个名为“member”的值,我可以很容易地将该值更改为“admin”.也许它不会起作用,但对于许多脚本,我可以即时访问任何管理员级别的信息.
简而言之,没有一种简单的方法来保护Web表单,但是有一些基本的原则可以简化您应该做的事情,从而减轻保护脚本的压力.
再一次好的措施：
>清理所有输入
>编码所有输出
>根据严格的白名单验证用于执行的任何输入
>确保输入来自实际用户
>永远不要进行任何用户或基于角色的验证浏览器端/用户可修改
永远不要认为任何一个人的名单都是详尽或完美的.
