会话劫持后可以做什么操作_什么是会话劫持以及如何阻止它

会话劫持后可以做什么操作

by Ramesh Lingappa

通过拉梅什·林加帕(Ramesh Lingappa)

什么是会话劫持以及如何阻止它 (What is session hijacking and how you can stop it)

This story is for beginners and anyone who has a basic understanding about cookies (sessions cookies), but who’s not sure how to secure them properly. You don’t have to be a security expert to do that. You just have to understand the process and then you will know.

本故事适用于初学者以及对cookie(会话cookie)有基本了解，但不确定如何正确保护它们的任何人。 您不必成为安全专家即可做到这一点。 您只需要了解该过程，便会知道。

If you don’t have any idea about cookies or how they work, then please read this article about HTTP Cookies.

如果您对Cookie或其工作方式一无所知，请阅读有关HTTP Cookies的文章。

Let's get to it! You have an amazing web application offering a great service for customers. That means you will have an Authentication mechanism to get the user to your application. You know how important security is. You implemented all sorts of security measures during authentication. Great!

让我们开始吧！ 您有一个了不起的Web应用程序，可以为客户提供优质的服务。 这意味着您将具有身份验证机制，以将用户吸引到您的应用程序。 您知道安全性的重要性。 您在身份验证期间实施了各种安全措施。 大！

Upon successful authentication, you must create a Session for that user. This means that you are actually creating a cookie and sending it back to the browser. For example, in a Java web app, by default, it’s called JSESSIONID. It looks something like this:

身份验证成功后，您必须为该用户创建一个会话 。 这意味着您实际上是在创建cookie并将其发送回浏览器。 例如，在Java Web应用程序中，默认情况下，它称为JSESSIONID。 看起来像这样：

By using this cookie, only your web server is able to identify who the user is and it will provide content accordingly. And this cookie looks great. No sensitive information in the cookie, just the random ID (non-guessable). So the user is Safe! …right?

通过使用此cookie，只有您的Web服务器才能识别用户是谁，并且它将相应地提供内容。 而且这个cookie看起来很棒。 Cookie中没有敏感信息，只有随机ID(不可猜测)。 因此用户是安全的！ …对？

Well not exactly, let’s take a closer look.

好吧，不完全是，让我们仔细看看。

There are two properties in this cookie: HttpOnly (HTTP) and Secure. Their values are blank, meaning not enabled for this cookie. That’s where it gets to the point that it’s no longer safe.

此cookie中有两个属性： HttpOnly(HTTP)和Secure。 它们的值为空，表示未为此cookie启用。 这就是它不再安全的地步。

This is where Session Hijacking comes into play.

这是会话劫持发挥作用的地方。

Session hijacking, sometimes also known as cookie hijacking is the exploitation of a valid computer session — sometimes also called a session key — to gain unauthorized access to information or services in a computer system. — Wikipedia

会话劫持 (有时也称为cookie 劫持)是利用有效的计算机会话 (有时也称为会话密钥)来获得对计算机系统中信息或服务的未授权访问。 — 维基百科

So it’s the act of stealing a customer’s session ID, by which they can access your web application as if they’re that customer.

因此，这是窃取客户会话ID的行为，他们可以通过该会话ID来访问您的Web应用程序，就像他们是该客户一样。

Is this possible? How do they get that session ID which is in the user’s browser?

这可能吗？ 他们如何获取用户浏览器中的会话ID？

Yes it’s possible. The two cookie properties (or flags) which we saw earlier (HttpOnly and Secure) are the reason for this.

是的，有可能。 我们前面看到的两个cookie属性(或标志)( HttpOnly和Secure )是这样做的原因。

HttpOnly标志 (HttpOnly Flag)

HttpOnly cookies are inaccessible to JavaScript's Document.cookie API; they are only sent to the server. For example, cookies that persist server-side sessions don't need to be available to JavaScript, and the HttpOnly flag should be set.

JavaScript的Document.cookie API无法访问HttpOnly cookie； 它们仅发送到服务器。 例如，持久化服务器端会话的cookie不需要对JavaScript可用，并且应该设置HttpOnly标志。

So in simple terms, if you don’t set the httpOnly flag, then your cookie is readable from the front end JavaScript code.

简单来说，如果您未设置httpOnly标志，则可以从前端JavaScript代码读取cookie。

Open any web page whose cookie doesn’t have the httpOnly flag set. Then open Chrome Dev Console and then tap Console Tab (Cmd + Shift+ J or Ctrl + Shift+ J). Type document.cookie and Enter, and you will see something like this:

打开其Cookie没有设置httpOnly标志的任何网页。 然后打开Chrome开发者控制台 ，然后点击控制台标签 (Cmd + Shift + J或Ctrl + Shift + J)。 输入document.cookie并按Enter，您将看到类似以下内容：

As you can see, you get all the cookie info. A JavaScript attacker can simply post this to their own server for later use.

如您所见，您将获得所有cookie信息。 JavaScript攻击者可以将其简单地发布到自己的服务器上，以供以后使用。

You might wonder how they can write this code in your Application. It’s possible in several ways.

您可能想知道他们如何在您的应用程序中编写此代码。 有几种可能。

One way is to inject some untrusted third-party JS library like logging, helper utilities, etc. Read this article I’m harvesting credit card numbers and passwords from your site. Here’s how.

一种方法是注入一些不受信任的第三方JS库，例如日志记录，帮助程序实用程序等。阅读本文， 我从您的站点中获取信用卡号和密码。 就是这样 。

Another way is by using a Cross Site Scripting Attack. We are not going to get into the details of it, but remember it can be done.

另一种方法是使用跨站点脚本攻击 。 我们不会详细介绍它，但是请记住它可以完成。

那么我们如何解决呢？ (So how do we fix it?)

The session cookie doesn’t even need to be accessible by the JavaScript client. It’s only needed for the server. We should make it only accessible for the server. It can be done by adding one word (httpOnly) in your set_cookie http response header. Like this:

会话cookie甚至不需要JavaScript客户端访问。 仅服务器需要。 我们应该使其只能由服务器访问。 可以通过在set_cookie http响应标头中添加一个单词( httpOnly )来完成。 像这样：

Set-Cookie: JSESSIONID=T8zK7hcII6iNgA; Expires=Wed, 21 May 2018 07:28:00 GMT; HttpOnly

By adding the httpOnly flag, you are instructing the browser that this cookie should not be read by the JavaScript code. The browser will take care of the rest. This is how it looks after adding the httpOnly flag:

通过添加httpOnly标志，您指示浏览器该JavaScript代码不应读取此cookie。 浏览器将处理其余的工作。 添加httpOnly标志后的外观如下：

Notice the tick mark in the HTTP property. That indicates that httpOnly is enabled.

请注意HTTP属性中的勾号。 这表示已启用httpOnly 。

Here you can see that document.cookie doesn’t return our session cookie. Meaning no JS can read it, including any external scripts.

在这里，您可以看到document.cookie不返回我们的会话cookie。 这意味着没有JS可以读取它，包括任何外部脚本。

That’s it — one down one to go!

就是这样-一下来就可以了！

安全标志 (Secure Flag)

The secure flag instructs the browser that the cookie should only be returned to the application over encrypted connections, that is, an HTTPS connection.

安全标志指示浏览器应仅通过加密连接(即HTTPS连接)将cookie返回给应用程序。

So, when a cookie is sent to the browser with the flag secure, and when you make a request to the application using HTTP, the browser won’t attach this cookie in the request. It will attach it only in an HTTPS request. The HTTPS request will be encrypted so cookies will be safely sent across the network to your application.

因此，在将cookie发送到带有安全标记的浏览器时，当您使用HTTP向应用程序发出请求时，浏览器不会在请求中附加该cookie。 它将仅将其附加在HTTPS请求中。 HTTPS请求将被加密，因此cookie将通过网络安全地发送到您的应用程序。

How can someone read the cookie in the HTTP request?

有人如何读取HTTP请求中的cookie？

This can be achieved when someone (called a “Man in the Middle” attack) is monitoring all the traffic in the network of customers. They are able to see the clear text data if the request is in HTTP.

当有人(称为“中间人”攻击)监视客户网络中的所有流量时，可以实现此目的。 如果请求使用HTTP，他们将能够看到明文数据。

When it’s sent over HTTPS, all data will be encrypted from the browser and sent to the network. The attacker won’t be able to get the raw data you were sending. Nor will the attacker be able to decrypt the content. This is why sending Data over SSL is secure.

通过HTTPS发送时，所有数据将从浏览器中加密并发送到网络。 攻击者将无法获取您正在发送的原始数据。 攻击者也无法解密内容。 这就是为什么通过SSL发送数据是安全的。

那么我们如何解决呢？ (So how do we fix it?)

Just like the httpOnly flag, you just need to add the secure flag in your set_cookie HTTP response header. Like this:

就像httpOnly标志一样，您只需要在set_cookie HTTP响应标头中添加安全标志。 像这样：

Set-Cookie: JSESSIONID=T8zK7hcII6iNgA; Expires=Wed, 21 May 2018 07:28:00 GMT; HttpOnly; Secure

In Java it can be done in several ways. If you are using Servlet 3.0 or above, then you can configure these settings in web.xml like this:

在Java中，可以通过多种方式完成。 如果您使用的是Servlet 3.0或更高版本，则可以在web.xml中配置这些设置，如下所示：

<session-config>    <cookie-config>        <http-only>true</http-only>        <secure>true</secure>    </cookie-config> </session-config>

If your environment doesn’t support it, then you can add it manually. For example using Servlets you can do this:

如果您的环境不支持它，那么您可以手动添加它。 例如，使用Servlet，您可以执行以下操作：

Finally, this is how it looks when both flags are set,

最后，这是设置两个标志时的外观，

结论 (Conclusion)

So when you are dealing with session cookies or any other important cookies, make sure you add these two flags.

因此，当您处理会话cookie或任何其他重要的cookie时，请确保添加这两个标志。

Thanks for reading, Happy Securing!

感谢您的阅读， 安全保护！

翻译自: https://www.freecodecamp.org/news/session-hijacking-and-how-to-stop-it-711e3683d1ac/

会话劫持后可以做什么操作