什么是正确的方式使Web表单输入安全的各种上下文？ [英] What is the correct way to make web form input safe for a variety of contexts?
问题描述
你们都认为是正确的（读取：最灵活，松散耦合，最强大等）的方法，使用户从网络输入安全地用于Web应用程序的各个部分？显然，我们可以为每个上下文使用相应的消毒功能（数据库，屏幕上显示，保存在磁盘等上），但是是否有一些通常的模式来处理不安全的数据并使其安全？有没有一个确定的方法来强制将其视为不安全，除非它被妥善安全？
像已经说过的那样当您担心Web安全性时，需要考虑几件事情。以下是一些基本原则：
- 避免将用户直接输入到集成到查询和变量中。
所以这意味着没有像 $ variable = $ _POST ['user_input'] 的东西。对于任何这样的情况，您将向用户传递过多的控制权。如果输入影响某些数据库查询，则始终有白名单来验证用户输入。如果查询是针对用户名，则对一个好的用户名列表进行验证。不要简单地进行用户输入删除的查询。
一个（可能）例外是一个搜索字符串。在这种情况下，您需要清理，简单的。
- 避免在没有卫生条件的情况下存储用户输入。
如果用户正在为其他用户创建个人资料或上传信息，则必须具有可接受的数据类型的白名单，或者删除任何内容那可能是恶意的。这不仅仅是为了您的系统的安全性，而是为您的其他用户（见下一点）。
- 绝不能从用户输出任何内容到浏览器没有剥离它。
这可能是安全顾问对我强调的最重要的事情。当用户收到输入时，您不能简单地依靠消毒输入。如果您没有自己编写输出，请始终确保通过对任何HTML字符进行编码或将其包装在< plaintext> 标记中，输出无害。如果用户A上传了一些javascript，从而危害到查看该页面的任何其他用户，这是开发人员的简单疏忽。晚上你会睡得更好，知道任何和所有的用户输出都不能做任何事情，只能在所有浏览器上显示为文字。
- 用户控制表单。
XSS比一个段落更容易，更容易覆盖。简单地说，无论何时创建表单，您都可以让用户访问将处理表单数据的脚本。如果我窃取某人的会话或某人的cookie，我现在可以跟脚本说话，就像我在表单页面上一样。我知道它预期的数据类型和它将要寻找的变量名称。我可以简单地传递这些变量，就像我是用户一样，脚本不能区别。
以上不是卫生问题，而是用户验证。我的最后一点与这个想法直接相关。
- 避免使用Cookie进行用户验证或角色验证。
如果我可以窃取用户的Cookie，我可能会做的不仅仅是让一个用户有一个糟糕的一天。如果我注意到cookie有一个名为member的值，我可以很容易地将该值更改为admin。也许这不行，但是对于许多脚本，我可以立即访问任何管理级别的信息。
简单地说，没有一个简单的方法来保护一个Web表单，但是有一些基本的原则可以简化你应该做的工作，从而减轻安全脚本的压力。
- 消除所有输入
- 编码所有输出
- 验证任何用于执行严格白名单的输入
- 确保输入来自实际用户
- 不要使用任何用户或基于角色的验证浏览器-side / user-modifiable
永远不要假设任何一个人的列表是穷尽的或完美的。
What do you all think is the correct (read: most flexible, loosely coupled, most robust, etc.) way to make user input from the web safe for use in various parts of a web application? Obviously we can just use the respective sanitization functions for each context (database, display on screen, save on disk, etc.), but is there some general "pattern" for handling unsafe data and making it safe? Is there an established way to enforce treating it as unsafe unless it is properly made safe?
Like it's already been said, there are several things to take into account when you are concerned about web security. Here are some basic principals to take into account:
- Avoid direct input from users being integrated into queries and variables.
So this means don't have something like $variable = $_POST['user_input']. For any situation like this, you are handing over too much control to the user. If the input affects some database query, always have whitelists to validate user input against. If the query is for a user name, validate against a list of good user names. Do NOT simply make a query with the user input dropped right in.
One (possible) exception is for a search string. In this case, you need to sanitize, simple as that.
- Avoid storing user input without sanitation.
If the user is creating a profile or uploading info for other users, you have to either have a white-list of what kind of data is acceptable, or strip out anything that could be malicious. This not only for your system's security, but for your other users (See next point.)
- NEVER output anything from a user to the browser without stripping it.
This is probably the most important thing that security consultants have emphasized to me. You can not simply rely on sanitizing input when it is received by the user. If you did not write the output yourself, always ensure that the output is innocuous by encoding any HTML characters or wrapping it in a <plaintext> tag. It is simple negligence on the part of the developer if user A uploads a bit of javascript that harms any other users that view that page. You will sleep better at night knowing that any and all user output can do nothing but appear as text on all browsers.
- Never allow anyone but the user control the form.
XSS is easier than it should be and a real pain to cover in one paragraph. Simply put, whenever you create a form, you are giving users access to a script that will handle form data. If I steal someone's session or someone's cookie, I can now talk to the script as though I was on the form page. I know the type of data it expects and the variables names it will look for. I can simply pass it those variables as though I were the user and the script can't tell the difference.
The above is not a matter of sanitation but of user validation. My last point is directly related to this idea.
- Avoid using cookies for user validation or role validation.
If I can steal a user's cookie, I may be able to do more than make that one user have a bad day. If I notice the cookie has a value called "member", I can very easily change that value to "admin". Maybe it won't work, but for many scripts, I would have instant access to any admin-level info.
Simply put, there is not one easy way to secure a web form, but there are basic principals that simplify what you should be doing, and thus eases the stress of securing your scripts.
Once more for good measure:
- Sanitize all input
- Encode all output
- Validate any input used for execution against a strict whitelist
- Make sure the input is coming from the actual user
- Never make any user or role-based validation browser-side/user-modifiable
And never assume that any one person's list is exhaustive or perfect.
这篇关于什么是正确的方式使Web表单输入安全的各种上下文？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
