java web快速入门
There are many reasons to learn about web security, such as:
了解网络安全的原因很多，例如：
and so on.
等等。
Well this post will explain some common web security acronyms in a way that is easy to understand but still accurate.
好吧，这篇文章将以一种易于理解但仍然准确的方式解释一些常见的Web安全缩写。
Before we do that, let’s make sure we understand a couple of core concepts of security.
在执行此操作之前，请确保我们已了解安全性的两个核心概念。
There is no notion of being 100% protected from being hacked. If anyone ever tells you that, they are wrong.
没有被100％保护免受黑客攻击的想法。 如果有人告诉你，那是错误的。
You can’t just say…
你不能只说...
Oh, because I have CSP implemented, I am safe. I can cross off cross-site scripting from my vulnerabilities list because that can’t happen now.
哦，因为我已经实施了CSP，所以我很安全。 我可以从漏洞列表中删除跨站点脚本，因为现在无法实现。
Maybe that is a given to some, but it is easy to find yourself thinking in this manner. I think one reason that programmers can easily find themselves thinking this way is because so much of coding is black and white, 0 or 1, true or false. Security is not so simple.
也许这是对某些人的肯定，但是很容易发现自己以这种方式思考。 我认为程序员可以轻松地以这种方式思考的原因之一是因为太多的编码是黑白的，即0或1，是对还是错。 安全性不是那么简单。
We’ll start off with one that everyone runs into fairly early on in their web development journey. And then you look on StackOverflow and find a bunch of answers telling you how to bypass it.
我们将从每个人在Web开发旅程的初期就遇到的一开始开始。 然后，您查看StackOverflow，找到一堆答案，告诉您如何绕过它。
Have you ever gotten an error that looked something like this?
您是否遇到过看起来像这样的错误？
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.You are certainly not alone. And then you Google it, and someone tells you to get this extension that will make all your problems go away!
您当然并不孤单。 然后，您使用Google进行搜索，有人告诉您获得此扩展程序，它将使您所有的问题都消除！
Great, right?
太好了吧？
CORS is there to protect you, not hurt you!
CORS在那里保护您，而不是伤害您！
In order to explain how CORS helps you, let’s first talk about cookies, specifically authentication cookies. Authentication cookies are used to tell a server that you are logged in, and they are automatically sent with any request you make to that server.
为了解释CORS如何为您提供帮助，让我们首先讨论Cookie，特别是身份验证Cookie 。 身份验证cookie用于告诉服务器您已登录，并且会随您对该服务器的任何请求一起自动发送。
Let’s say you’re logged in to Facebook, and they use authentication cookies. You click on bit.ly/r43nugi which redirects you to superevilwebsite.rocks. A script within superevilwebsite.rocks makes a client-side request to facebook.com which sends your authentication cookie!
假设您已登录Facebook，并且他们使用身份验证cookie。 您单击bit.ly/r43nugi ，将您重定向到superevilwebsite.rocks 。 superevilwebsite.rocks的脚本向facebook.com发出客户端请求，该请求将发送您的身份验证cookie！
In a no-CORS world, they could make changes to your account without you even knowing. Until, of course, they post bit.ly/r43nugi on your timeline, and all of your friends click on it, and then they post bit.ly/r43nugi on all of your friends’ timelines and then the cycle continues in an evil breadth-first scheme that conquers all of Facebook’s users, and the world is consumed by superevilwebsite.rocks. ?
在没有CORS的世界中，他们甚至可能在您不知情的情况下更改您的帐户。 当然，直到他们在您的时间轴上发布bit.ly/r43nugi ，并且您所有的朋友都单击它，然后他们在您所有朋友的时间轴上发布bit.ly/r43nugi ，然后该循环才继续发展第一种方案，它征服了Facebook的所有用户， superevilwebsite.rocks消耗了superevilwebsite.rocks世界。 ？
In a CORS world, however, Facebook would only allow requests with an origin of facebook.com to edit data on their server. In other words, they would limit cross-origin resource sharing. You might then ask…
但是，在CORS世界中，Facebook仅允许起源于facebook.com请求在其服务器上编辑数据。 换句话说，它们将限制跨域资源共享。 然后您可能会问...
Well can superevilwebsite.rocks just change the origin header on their request, so that it looks like it is coming from facebook.com?
难道superevilwebsite.rocks可以根据他们的请求更改原始标头，以使其看起来像来自facebook.com吗？
They can try, but it won’t work because the browser will just ignore it and use the real origin.
他们可以尝试，但不会起作用，因为浏览器只会忽略它并使用真实来源。
Ok, but what if superevilwebsite.rocks made the request server-side?
好的，但是如果superevilwebsite.rocks在服务器端发出了请求怎么办？
In this case, they could bypass CORS, but they will not win because they won’t be able to send your authentication cookie along for the ride. The script would need to execute on the client side to get access to your client side cookies.
在这种情况下，他们可以绕过CORS，但他们不会获胜，因为他们将无法随身发送您的身份验证Cookie。 该脚本需要在客户端上执行才能访问您的客户端cookie。
To understand CSP, we first need to talk about one of the most common vulnerabilities on the web: XSS, which stands for cross-site scripting (yay — another acronym).
要了解CSP，我们首先需要讨论Web上最常见的漏洞之一：XSS，它表示跨站点脚本(是，另一个缩写)。
XSS is when some evil person injects JavaScript into your client-side code. You might think…
XSS是当某些邪恶的人将JavaScript注入您的客户端代码中时。 你可能认为…
What are they going to do? Change a color from red to blue?
他们将要做什么？ 将颜色从红色更改为蓝色？
Let’s assume that someone has successfully injected JavaScript into client-side code of a website you are visiting.
假设有人成功将JavaScript注入了您正在访问的网站的客户端代码中。
What could they do that would be malicious?
他们该怎么办才是恶意的？
The possibilities are endless.
可能性是无止境。
CSP tries to prevent this from happening by limiting:
CSP试图通过限制以下内容来防止这种情况的发生：
So how does it work?
那么它是怎样工作的？
When you click on a link or type a website URL in the address bar of your browser, your browser makes a GET request. It eventually makes its way to a server which serves up HTML along with some HTTP headers. If you’re curious about what headers you receive, open up the Network tab in your console, and visit some websites.
当您单击链接或在浏览器的地址栏中键入网站URL时，浏览器会发出GET请求。 它最终进入服务器，该服务器提供HTML和一些HTTP标头。 如果您对收到的标头感到好奇，请在控制台中打开“网络”选项卡，然后访问一些网站。
You might see a response header that looks like this:
您可能会看到一个响应标头，如下所示：
content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;That is the content security policy of facebook.com. Let’s reformat it to make it easier to read:
那是facebook.com的内容安全策略。 让我们对其重新格式化以使其更易于阅读：
content-security-policy:
default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;Now, let’s break down the directives.
现在，让我们分解一下指令。
default-src restricts all other CSP directives that are not explicitly listed.
default-src限制所有其他未明确列出的CSP指令。
script-src restricts the scripts that can be loaded.
script-src 限制可以加载的脚本。
style-src restricts the stylesheets that can be loaded.
style-src限制可以加载的样式表。
connect-src restricts the URLs which can be loaded using script interfaces, so fetch, XHR, ajax, etc.
connect-src限制了可以使用脚本接口加载的URL，因此，fetch，XHR，ajax等。
Note that there are many more CSP directives than just these four shown above. The browser will read the CSP header and apply those directives to everything within the HTML file that was served. If the directives are set appropriately, they allow only what is necessary.
请注意，除了上面显示的这四个指令外，还有更多的CSP指令。 浏览器将读取CSP标头，并将这些指令应用于所提供HTML文件中的所有内容。 如果指令设置正确，则它们仅允许必要的内容。
If no CSP header is present, then everything goes, and nothing is restricted. Everywhere you see * , that is a wildcard. You can imagine replacing * with anything and it will be allowed.
如果没有CSP标头，则一切顺利，并且没有任何限制。 您在所有看到*地方都是通配符。 您可以想象将*替换为任何东西，它将被允许。
Certainly you have heard about HTTPS. Maybe you have heard some people say…
当然，您已经听说过HTTPS。 也许您听到有人说...
Why do I care about using HTTPS if I am just on a website playing a game.
如果我只是在玩游戏的网站上，为什么还要关心使用HTTPS。
Or maybe you have heard the other side…
或者，也许您听到了另一边的声音……
You are crazy if your site doesn’t have HTTPS. It’s 2018! Don’t trust anyone that says otherwise.
如果您的站点没有HTTPS，您会发疯。 是2018年！ 不要相信任何其他人。
Maybe you heard that Chrome will now mark your site as insecure if it is not HTTPS.
也许您听说过，如果不是HTTPS，Chrome现在会将您的网站标记为不安全。
At its core, HTTPS is fairly straightforward. HTTPS is encrypted and HTTP is not.
从本质上讲，HTTPS非常简单。 HTTPS已加密，HTTP未加密。
So why does this matter if you are not sending sensitive data?
那么，如果您不发送敏感数据，为什么这很重要呢？
Get ready for another acronym…MITM, which stands for Man in the Middle.
准备使用另一个缩写词……MITM，它代表中间人。
If you are using public Wi-Fi with no password at a coffee shop, it’s pretty easy for someone to act like your router, so that all requests and responses go through them. If your data is not encrypted, then they can do whatever they want with it. They can edit the HTML, CSS, or JavaScript before it even gets to your browser. Given what we know about XSS, you can imagine how bad this could be.
如果您在咖啡店使用不带密码的公共Wi-Fi，则很容易有人像您的路由器那样工作，以便所有请求和响应都通过它们。 如果您的数据未加密，则他们可以随心所欲地对其进行处理。 他们甚至可以在HTML，CSS或JavaScript进入浏览器之前对其进行编辑。 根据我们对XSS的了解，您可以想象这有多糟糕。
Ok, but how is it that my computer and the server know how to encrypt/decrypt but this MITM does not?
好的，但是我的计算机和服务器如何知道如何加密/解密，而该MITM却不知道如何加密？
That’s where SSL (Secure Sockets Layer) and more recently, TLS (Transport Layer Security) come in. TLS took over for SSL in 1999 as the encryption technology used within HTTPS. Exactly how TLS works is outside of the scope of this post.
这就是SSL(安全套接字层)以及最近的TLS(传输层安全性)出现的地方。TLS在1999年取代SSL成为HTTPS中使用的加密技术。 TLS的确切工作方式不在本文讨论范围之内。
This one is pretty straightforward. Let’s use Facebook’s header as an example again:
这很简单。 让我们再次使用Facebook标头作为示例：
strict-transport-security: max-age=15552000; preloadmax-age specifies how long a browser should remember to force the user to access a website using HTTPS.
max-age指定浏览器应记住强迫用户使用HTTPS访问网站的时间。
preload is not important for our purposes. It is a service hosted by Google and not part of the HSTS specification.
preload对我们的目的并不重要。 它是Google托管的服务，不是HSTS规范的一部分。
This header only applies if you accessed the site using HTTPS. If you accessed the site via HTTP, the header is ignored. The reason is that, quite simply, HTTP is so insecure that it can’t be trusted.
仅当您使用HTTPS访问该网站时，此标题才适用。 如果您通过HTTP访问该站点，则标题将被忽略。 原因很简单，HTTP不安全，无法信任。
Let’s use the Facebook example to further illustrate how this is helpful in practice. You are accessing facebook.com for the first time, and you know HTTPS is safer than HTTP, so you access it over HTTPS, https://facebook.com. When your browser receives the HTML, it receives the header above which tells your browser to force-redirect you to HTTPS for future requests. One month later, someone sends you a link to Facebook using HTTP, http://facebook.com, and you click on it. Since one month is less than the 15552000 seconds specified by the max-age directive, your browser will send the request as HTTPS, preventing a potential MITM attack.
让我们使用Facebook示例进一步说明这在实践中有何帮助。 您是第一次访问facebook.com ，并且知道HTTPS比HTTP安全，因此您可以通过HTTPS https://facebook.com访问。 当您的浏览器收到HTML时，它会收到上面的标头，该标头告诉您的浏览器为将来的请求将您强制重定向到HTTPS。 一个月后，有人使用HTTP( http://facebook.com向您发送了指向Facebook的链接，然后单击它。 由于一个月少于max-age指令指定的15552000秒，因此您的浏览器将以HTTPS形式发送请求，从而防止了潜在的MITM攻击。
Web security is important no matter where you are in your web development journey. The more you expose yourself to it, the better off you will be. Security is something that should be important to everyone, not just the people who have it explicitly named in their job title! ?
无论您在Web开发过程中的何处，Web安全都是重要的。 您对它的了解越多，您的生活就会越好。 安全对每个人都应该是重要的，而不仅仅是在职称中明确指定安全的人！ ？
翻译自: https://www.freecodecamp.org/news/a-quick-introduction-to-web-security-f90beaf4dd41/
java web快速入门
版权声明：本站所有资料均为网友推荐收集整理而来,仅供学习和研究交流使用。
工作时间：8:00-18:00
客服电话
电子邮件
admin@qq.com
扫码二维码
获取最新动态
