Security 攻击者能否有害地使用inspect元素？

我知道这是一个广泛的问题，但我想我遗漏了一些东西。攻击者是否可以通过简单地使用inspect元素并编辑javascript和html对站点造成损害？例如，对于某些人来说，更改输入的maxlength似乎太容易了，上传的数据太多了，可能会使服务器崩溃。我知道，在服务器上检查数据总是一种很好的做法，但似乎仍然太容易了。或者另一个更具潜在危险的例子是，攻击者可以干扰

$.ajax

调用并向服务器发送错误信息。在攻击者的浏览器上，这是我应该更加担心的事情，还是这些更改只是暂时的？

您应该对此感到担忧。永远不要相信来自客户端的输入。不要期望在客户端执行的任何检查都会被真正执行。您始终需要检查服务器端的输入。

---

正如您已经提到的，用户可以使用各种检查工具来更改本地代码，或者完全手工制作恶意数据包

这些更改在单个用户的浏览器上是临时的

但是，这些更改将允许该用户以其选择的方式与您的后端交互。这是网站受到攻击的一种方式

标准规则是永远不要相信来自用户/浏览器的输入。不要相信隐藏字段的值，不要相信它们没有更改长度，不要相信它们没有添加新值（例如下拉列表），不要相信在Javascript中进行的任何验证，等等

一些例子：

• 过去的一些购物网站会将支付金额作为隐藏字段包含在表单中。更改此值会在仍批准交易的情况下更改信用卡的收费金额
• 具有Javascript验证规则的站点可以通过直接发布到后端服务来跳过这些规则，从而使自己受到SQL和HTML/脚本注入攻击
• 下拉列表、单选按钮和复选框输入，可在其中向表单中添加意外值

---

是的，他们可以。当他们检查元素时，他们可以在本地修改所有内容，因此这将是对其本地环境的临时修改，但是他们可以修改可能影响服务器的值
例如，假设您有一个在线商店，并且您有一个“编辑产品”选项。一旦你去了那里，你有一个隐藏的字段，在那里你存储产品ID，这样当你试图在你的后端更新该产品时，你将使用该ID来知道该更新哪个产品。攻击者可以轻松更改该值，现在他可以修改任何其他产品（包括不属于他的产品）
另一个典型的例子是数字字段，您假设用户只能提交数值，因此在后端，您可以在查询中使用该数字，例如

"SELECT * FROM Products WHERE Price > " + Price;

您期望的是一个数字值，因此您认为攻击者无法发送用于SQL注入的文本，但他可以轻松修改该值（通过更改文本输入的数字输入、在发送之前修改javascript值，或者拦截网络流量并从中修改值），现在你可以得到这样的结果：

"SELECT * FROM Products WHERE Price > 0; DROP TABLE Products--"

这就是你永远不应该相信用户输入的主要原因。您需要一个数值吗？然后在使用之前确保它是一个数字。您的用户正在更新产品吗？在更新产品之前，确保产品确实属于他。您的数据是否具有maxlength属性？仔细检查服务器，确保它仍然具有有效的长度
这可能看起来很简单，但人们会犯错误。一个简单的例子是“Heart Bleed”bug，通过验证请求的长度，而不是信任用户提交的数据，可以避免所有这一切

---

这就是为什么您永远不需要信任用户提交的数据，并且始终在后端执行双重检查的主要原因。
是的，他们可以。他们可以查看您的代码，让他们有机会发现漏洞或创建漏洞并攻击该漏洞。即使这些编辑是临时的，并且只在攻击者的浏览器上进行，它们也会造成伤害。
答案是肯定的。他们根本不必使用web浏览器。他们可以在你的站点上抛出他们想要的任何该死的网络请求，这看起来可能与正常使用中发生的情况完全不同。你必须准备好面对看起来几乎任何东西的请求。特雷弗的回答补充道：海报将有助于了解网站在实践中是如何受到攻击的。几乎每个黑客都会使用。好吧，所有这些答案都吓坏我了！我想我需要非常小心服务器端验证。伟大的回答顺便说一句！澄清：他们只能看到客户端代码，但仍然可能存在并发现漏洞。你能补充更多关于如何实现这一点的细节吗？OP已经列举了一些人们可能会担心的场景。