web表单设计:点石成金_如何设计安全的Web表单：验证，清理和控制-CSDN博客

web表单设计:点石成金

While cybersecurity is often thought of in terms of databases and architecture, much of a strong security posture relies on elements in the domain of the front-end developer.

尽管通常从数据库和体系结构的角度来考虑网络安全，但是强大的安全状态在很大程度上取决于前端开发人员领域中的元素。

For certain potentially devastating vulnerabilities like SQL injection and Cross-Site Scripting (XSS), a well-considered user interface is the first line of defense.

对于某些潜在的破坏性漏洞(如SQL注入和跨站点脚本(XSS)) ，精心设计的用户界面是第一道防线。

Here are a few areas of focus for front-end developers who want to help fight the good fight.

这是希望帮助打好仗的前端开发人员的一些重点领域。

控制用户输入 (Control user input)

A whole whack of crazy things can happen when developers build a form that fails to control user input. To combat vulnerabilities like injection, it’s important to validate or sanitize user input.

当开发人员构建无法控制用户输入的表单时，可能会发生疯狂的事情。为了解决诸如注入之类的漏洞，验证或清除用户输入很重要。

You can validate input by constraining it to known values, such as by using semantic input types or validation-related attributes in forms. Frameworks like Django also help by providing field types for this purpose. Sanitizing data can be done by removing or replacing contextually-dangerous characters, such as by using a whitelist or escaping the input data.

您可以通过将输入约束为已知值来验证输入，例如使用语义输入类型或表单中与验证相关的属性。 Django之类的框架也通过为此提供字段类型来提供帮助。可以通过删除或替换上下文相关的危险字符来对数据进行消毒，例如使用白名单或转义输入数据。

While it may not be intuitive, even data that a user submits to their own area on a site should be validated. One of the fastest viruses to proliferate was the Samy worm on MySpace (yes, I’m old), thanks to code that Samy Kamkar was able to inject into his own profile page. Don’t directly return any input to your site without thorough validation or sanitization.

尽管这可能不直观，但即使是用户提交到站点上自己区域的数据也应进行验证。传播速度最快的病毒之一是MySpace上的Samy蠕虫 (是的，我很老)，这要归功于Samy Kamkar能够将其注入自己的个人资料页面的代码。未经彻底验证或消毒，请勿直接将任何输入返回到您的站点。

For some further guidance on battling injection attacks, see the OWASP Injection Prevention Cheat Sheet.

有关对抗注入攻击的更多指导，请参阅《 OWASP注入预防速查表》。

当心隐藏的领域 (Beware of hidden fields)

Adding type="hidden" is an enticingly convenient way to hide sensitive data in pages and forms, but unfortunately not an effective one.

添加type="hidden"是在页面和表单中隐藏敏感数据的一种非常方便的方法，但是不幸的是，这不是一种有效的方法。

With tools like ZapProxy and even inspection tools in plain ol’ web browsers, users can easily click to reveal tasty bits of invisible information.

借助ZapProxy之类的工具，甚至是普通Web浏览器中的检查工具，用户都可以轻松地单击以显示一些鲜美的隐形信息。

Hiding checkboxes can be a neat hack for creating CSS-only switches, but hidden fields do little to contribute to security.

隐藏复选框对于创建仅CSS的开关可能是个好办法，但是隐藏字段对安全性的贡献很小。

If you must use hidden fields, here are some helpful guidelines.

如果您必须使用隐藏字段，则这里有一些有用的准则。

仔细考虑自动填充字段 (Carefully consider autofill fields)

When a user chooses to give you their Personally Identifiable Information (PII), it should be a conscious choice. Autofill form fields can be convenient - for both users and attackers. Exploits using hidden fields can harvest PII previously captured by an autocomplete field.

当用户选择向您提供其个人身份信息 (PII)时，这应该是一种有意识的选择。自动填充表单字段可能很方便-对于用户和攻击者都如此。使用隐藏字段的漏洞利用可以收获以前由自动完成字段捕获的PII 。

Many users aren’t even aware what information their browser’s autofill has stored up. Use these fields sparingly, and disable autofilled forms for particularly sensitive data.

许多用户甚至都不知道其浏览器的自动填充存储了哪些信息。谨慎使用这些字段，并对特别敏感的数据禁用自动填充的表单。

It’s important to also weigh your risk profile against its trade-offs. If your project must be WCAG compliant, disabling autocomplete can break your input for different modalities. For more, see 1.3.5: Identify Input Purpose in WCAG 2.1.

重要的是还要权衡您的风险状况与权衡取舍。如果您的项目必须符合WCAG ，则禁用自动完成功能可能会破坏您对不同模式的输入。有关更多信息，请参见1.3.5：在WCAG 2.1中标识输入目的。

保持错误通用 (Keep errors generic)

While it may seem helpful to let users know whether a piece of data exists, it’s also very helpful to attackers. When dealing with accounts, emails, and PII, it’s most secure to err (🥁) on the side of less. Instead of returning “Your password for this account is incorrect,” try the more ambiguous feedback “Incorrect login information,” and avoid revealing whether the username or email is in the system.

让用户知道某条数据是否存在似乎有所帮助，但对攻击者也非常有帮助。在处理帐户，电子邮件和PII时，最安全的做法是减少错误(🥁)。尝试返回更模糊的反馈“错误的登录信息”，而不是返回“此帐户的密码不正确”，并避免显示系统中是否包含用户名或电子邮件。

In order to be more helpful, provide a prominent way to contact a human in case an error should arise. Avoid revealing information that isn’t necessary. If nothing else, for heaven’s sake, don’t suggest data that’s a close match to the user input.

为了提供更多帮助，请提供一种重要的方式来与人联系，以防发生错误。避免泄露不必要的信息。出于天堂的考虑，如果没有其他建议，请不要建议与用户输入内容非常匹配的数据。

做个坏人 (Be a bad guy)

When considering security, it’s helpful to take a step back, observe the information on display, and ask yourself how a malicious attacker would be able to utilize it. Play devil’s advocate. If a bad guy saw this page, what new information would they gain? Does the view show any PII?

考虑安全性时，退后一步，观察显示的信息，并询问自己恶意攻击者如何利用它，将很有帮助。扮演魔鬼的拥护者。如果有坏人看到此页面，他们将获得什么新信息？该视图是否显示任何PII？

Ask yourself if everything on the page is actually necessary for a genuine user. If not, redact or remove it. Less is safer.

问问自己，页面上的所有内容对于真正的用户是否确实必要。如果不是，请编辑或删除它。少则安全。

安全性从前门开始 (Security starts at the front door)

These days, there’s a lot more overlap between coding on the front end and the back end. To create a well-rounded and secure application, it helps to have a general understanding of ways attackers can get their foot in the front door.

如今，前端和后端的编码之间有很多重叠。要创建一个全面而安全的应用程序，有助于大致了解攻击者如何进入前门。