java 后端数据校验_后端数据验证

java 后端数据校验

It’s no secret that the list of 100 largest companies in the world by market value features many tech companies. In particular, it features software companies.

众所周知， 按市值列出的全球100家最大的公司中有许多高科技公司。 特别是它具有软件公司的特色。

Apple, Microsoft, Amazon, Alphabet, Facebook, and Alibaba occupy six of the top seven positions, proving beyond any reasonable doubt that software rules the world. But if software is omnipresent today, so are software bugs.

苹果，微软，亚马逊，Alphabet，Facebook和阿里巴巴占据了前七名中的第六名，这毫无疑问地证明了软件统治着世界。 但是，如果今天软件无所不在，那么软件错误也是如此。

In this piece, we’ll discuss one of the most common mistakes that can lead to catastrophic results. We’ll see how such a mistake manifests in your code and a learn simple approach to avoid it.

在本文中，我们将讨论可能导致灾难性结果的最常见错误之一。 我们将看到这种错误如何在您的代码中体现出来，并提供了一种避免这种错误的简单学习方法。

永远不要信任您的用户 (Never Trust Your User)

“Never trust your user” is one of those clichés you’ve probably heard if you’ve been writing software for more than a few months. In other words: Never trust any information submitted by a user. Whoever first said this was absolutely right!

如果您编写软件已经有几个月以上了，那么“永远不要信任您的用户”就是您可能会听到的陈词滥调之一。 换句话说：永远不要信任用户提交的任何信息。 谁先说这是绝对正确的！

What happens in the user’s browser when running the front end code you’ve developed is beyond your control. Essentially, the browser is a black box that, at some point, after the user has interacted with your code, might send you back a certain piece of data. How can you be unconditionally sure that this data has been generated as a result of the execution of your trusted code? Well, you can’t.

运行您开发的前端代码时，用户浏览器中发生的事情是无法控制的。 本质上，浏览器是一个黑匣子，在用户与您的代码进行交互之后的某个时候，它可能会将您发送回某些数据。 您如何无条件地确定此数据是由于执行受信任代码而生成的？ 好吧，你不能。

Let’s take a look at an example. You’ll see first-hand why trusting user data is a bad idea.

让我们看一个例子。 您将直接了解为什么信任用户数据是个坏主意。

恶意数据提交 (A Malicious Data Submission)

Let’s imagine a banking application that allows users to transfer funds from one account to another:

让我们想象一个银行应用程序，它允许用户将资金从一个帐户转移到另一个帐户：

An imaginary banking application (image by author)

虚构的银行业务申请(作者提供的图片)

When the user clicks on the Transfer button in the above scenario, your front end data validation code kicks in. It checks that there are enough funds in your account to allow you to proceed with the transfer and notifies you with an error message if not:

在上述情况下，当用户单击“ Transfer按钮时，您的前端数据验证代码会启动。它将检查您帐户中是否有足够的资金可以进行转移，如果没有，则通过错误消息通知您：

A sample frontend data validation scenario (image by author)

前端数据验证场景示例(作者提供的图像)

If you have a similar data validation scenario in your project, not backed by appropriate backend checks, there are many things that can go wrong here.

如果您的项目中有类似的数据验证方案，并且没有适当的后端检查支持，那么这里可能有很多问题。

禁用JavaScript (Disabling JavaScript)

The user might simply disable JavaScript in the browser:

用户可能只是在浏览器中禁用了JavaScript：

Disabling JavaScript in Chrome (image by author)

在Chrome中禁用JavaScript(作者提供的图片)

In that case, the validation logic won’t run. Provided your application still works with JavaScript disabled, the transfer funds request will be submitted, executing a $150 transfer on an account with only $100 balance.

在这种情况下，验证逻辑将不会运行。 如果您的应用程序仍可在禁用JavaScript的情况下运行，则将提交转帐资金请求，并在帐户余额为$ 100的情况下执行$ 150的转帐。

修改来源 (Modifying sources)

The source of the page and the underlying JavaScript code can be easily manipulated to do anything a malicious user might want:

该页面的源代码和底层JavaScript代码可以轻松地进行操作，以执行恶意用户可能想要的任何事情：

Manipulating the source of the page to display just anything — this is not Photoshopped (image by author)

操纵页面的源以显示所有内容-这不是Photoshop处理(作者提供的图像)

Similarly, the JavaScript code validating the balance and the amount to be transferred can be completely commented out or changed to allow all kinds of erroneous transfers.

同样，验证余额和要转账金额JavaScript代码可以完全注释掉或更改，以允许各种错误的转账。

请求捕获，修改和重放 (Request capturing, modifying, and replaying)

Finally, the actual data submission request can be intercepted, captured, changed, and replayed. During the replay, a malicious user can change the body of the request to submit just any data they wish. If you’re interested in how to capture and replay REST requests, you can have a look at a previous piece of mine:

最后，实际的数据提交请求可以被拦截，捕获，更改和重放。 在重播期间，恶意用户可以更改请求的主体以仅提交他们希望的任何数据。 如果您对如何捕获和重播REST请求感兴趣，可以看一下我的上一篇文章：

So, how such a threat can be mitigated, or — even better— completely eliminated?

那么，如何减轻或什至完全消除这种威胁呢？

后端验证 (Backend Validations)

Irrespective of front end technology and framework, your back end will eventually end up receiving a data request. It’s how you treat the content of that request that makes a difference.

无论前端技术和框架如何，您的后端最终都会收到数据请求。 对待请求内容的方式与众不同。

A quick recap: Never trust the data submitted by the user.

快速回顾：永远不要信任用户提交的数据。

Every bit of data submitted by your user has to be validated on your back end. Discard any information that you can obtain by querying your underlying data sources and keep only what is intrinsic to the actual request being handled. Here’s how you could validate the malicious request presented above:

用户提交的每一位数据都必须在后端进行验证。 丢弃可以通过查询基础数据源获得的任何信息，并仅保留要处理的实际请求所固有的内容。 这是验证上面提出的恶意请求的方法：

A backend validation flow (image by author)

后端验证流程(作者提供的图片)

The back end validation code not only checked, independently of the frontend, that the user has sufficient funds but also validated the real system ID of the user (using a security token/header passed along with the request) as well as the corresponding source account for that user. The transfer was eventually allowed only when all independently-checked conditions were satisfied.

后端验证代码不仅独立于前端检查用户是否有足够的资金，而且还验证了用户的真实系统ID(使用与请求一起传递的安全令牌/标头)以及相应的源帐户对于该用户。 最终只有在所有独立检查的条件都满足时才允许转移。

Of course, real banking software systems might need to perform more complex data validations than that shown above. However, basic validation checks such as these should always be part of your back end code.

当然，实际的银行软件系统可能需要执行比上面显示的更为复杂的数据验证。 但是，诸如此类的基本验证检查应始终是后端代码的一部分。

Implementing back end validation checks guarantees that any kind of malicious request has the chance to be re-checked in an environment you control. This is the only way to ensure that you, as the developer, have the final word on whether something should be executed or not.

实施后端验证检查可确保任何种类的恶意请求都有机会在您控制的环境中重新检查。 这是确保您(作为开发人员)对是否应该执行某些事情有最终决定权的唯一方法。

结论 (Conclusion)

If you’re a junior developer reading this piece, I hope you had the chance to learn something and next time you implement a data submission functionality you think of backend validations too. If you’re a mid/senior developer, you probably nod your head with a little sigh — you’ve seen these mistakes way too many times. Hopefully, you had the chance to catch them in a code review instead of prod!

如果您是初级程序员，请阅读本文，希望您有机会学习一些知识，下次希望实现数据提交功能时，也请考虑一下后端验证。 如果您是中高级开发人员，则可能会稍感叹息-您已经多次看到这些错误。 希望您有机会在代码审查中找到他们，而不是产品！

In conclusion, never trust your user and always perform back end data validation checks.

总之，永远不要信任您的用户，并且始终执行后端数据验证检查。

Thank you for reading this piece. I hope to see you on the next one.

感谢您阅读本文。 我希望在下一个再见。

翻译自: https://medium.com/better-programming/back-end-data-validations-73ea9004c6d7

java 后端数据校验