精华内容
下载资源
问答
  • 会话劫持

    2019-10-05 02:30:54
    1、简介  在现实生活中,比如你去市场买菜,在交完钱后你要求先去干一些别的事情,稍候再来拿菜;如果这个时候某个陌生人要求把菜拿走,卖菜的人会把菜给陌生人吗?...而会话劫持(Session Hijack)...

    1、简介

      在现实生活中,比如你去市场买菜,在交完钱后你要求先去干一些别的事情,稍候再来拿菜;如果这个时候某个陌生人要求把菜拿走,卖菜的人会把菜给陌生人吗?!当然,这只是一个比喻,但这恰恰就是会话劫持的喻意。所谓会话,就是两台主机之间的一次通讯。例如你Telnet到某台主机,这就是一次Telnet会话;你浏览某个网站,这就是一次HTTP会话。而会话劫持(Session Hijack),就是结合了嗅探以及欺骗技术在内的攻击手段。例如,在一次正常的会话过程当中,攻击者作为第三方参与到其中,他可以在正常数据包中插入恶意数据,也可以在双方的会话当中进行简听,甚至可以是代替某一方主机接管会话。

      我们可以把会话劫持攻击分为两种类型:

      1)中间人攻击(Man In The Middle,简称MITM)

      2)注射式攻击(Injection)

      并且还可以把会话劫持攻击分为两种形式:

      1)被动劫持,被动劫持实际上就是在后台监视双方会话的数据流,丛中获得敏感数据

      2)主动劫持,而主动劫持则是将会话当中的某一台主机“踢”下线,然后由攻击者取代并接管会话,这种攻击方法危害非常大,攻击者可以做很多事情

    2、MITM攻击简介 

      这也就是我们常说的“中间人攻击”,在网上讨论比较多的就是SMB会话劫持,这也是一个典型的中间人攻击。要想正确的实施中间人攻击,攻击者首先需要使用ARP欺骗DNS欺骗,将会话双方的通讯流暗中改变,而这种改变对于会话双方来说是完全透明的。

      关于ARP欺骗黑客防线介绍的比较多,网上的资料也比较多,我就不在多说了,我只简单谈谈DNS欺骗。DNS(Domain Name System),即域名服务器,我们几乎天天都要用到。对于正常的DNS请求,例如在浏览器输入www.hacker.com.cn,然后系统先查看Hosts文件,如果有相对应的IP,就使用这个IP地址访问网站(其实,利用Hosts文件就可以实现DNS欺骗);如果没有,才去请求DNS服务器;DNS服务器在接收到请求之后,解析出其对应的IP地址,返回给我本地,最后你就可以登陆到黑客防线的网站。而DNS欺骗则是,目标将其DNS请求发送到攻击者这里,然后攻击者伪造DNS响应,将正确的IP地址替换为其他IP,之后你就登陆了这个攻击者指定的IP,而攻击者早就在这个IP中安排好了恶意网页,可你却在不知不觉中已经被攻击者下了“套”……DNS欺骗也可以在广域网中进行,比较常见的有“Web服务器重定向”、“邮件服务器重定向”等等。但不管是ARP欺骗,还是DNS欺骗,中间人攻击都改变正常的通讯流,它就相当于会话双方之间的一个透明代理,可以得到一切想知道的信息,甚至是利用一些有缺陷的加密协议来实现。

    3、注射式攻击简介 

      这种方式的会话劫持比中间人攻击实现起来简单一些,它不会改变会话双方的通讯流,而是在双方正常的通讯流插入恶意数据。在注射式攻击中,需要实现两种技术:

      1)IP欺骗

      2)预测TCP序列号

      如果是UDP协议,只需伪造IP地址,然后发送过去就可以了,因为UDP没有所谓的TCP三次握手,但基于UDP的应用协议有流控机制,所以也要做一些额外的工作。对于IP欺骗,有两种情况需要用到:

      1)隐藏自己的IP地址;

      2)利用两台机器之间的信任关系实施入侵。

      在Unix/Linux平台上,可以直接使用Socket构造IP包,在IP头中填上虚假的IP地址,但需要root权限;在Windows平台上,不能使用Winsock,需要使用Winpacp(也可以使用Libnet)。例如在Linux系统,首先打开一个Raw Socket(原始套接字),然后自己编写IP头及其他数据。可以参考下面的实例代码: 

    sockfd = socket(AF_INET, SOCK_RAW, 255); 
    setsockopt(sockfd, IPPROTO_IP, IP_HDRINCL, &on, sizeof(on));

    struct ip *ip; 
    struct tcphdr *tcp; 
    struct pseudohdr pseudoheader; 
    ip->ip_src.s_addr = xxx; 
    pseudoheader.saddr.s_addr = ip->ip_src.s_addr; 
    tcp->check = tcpchksum((u_short *)&pseudoheader,12+sizeof(struct tcphdr)); 
    sendto(sockfd, buf, len, 0, (const sockaddr *)addr, sizeof(struct sockaddr_in));

      对于基于TCP协议的注射式会话劫持,攻击者应先采用嗅探技术对目标进行简听,然后从简听到的信息中构造出正确的序列号,如果不这样,你就必须先猜测目标的ISN(初始序列号),这样无形中对会话劫持加大了难度。那为什么要猜测会话双方的序列号呢?请继续往下看。

    4、TCP会话劫持

      本文主要叙述基于TCP协议的会话劫持。如果劫持一些不可靠的协议,那将轻而易举,因为它们没有提供一些认证措施;而TCP协议被欲为是可靠的传输协议,所以要重点讨论它。 
    根据TCP/IP中的规定,使用TCP协议进行通讯需要提供两段序列号,TCP协议使用这两段序列号确保连接同步以及安全通讯,系统的TCP/IP协议栈依据时间或线性的产生这些值。在通讯过程中,双方的序列号是相互依赖的,这也就是为什么称TCP协议是可靠的传输协议(具体可参见RFC 793)。如果攻击者在这个时候进行会话劫持,结果肯定是失败,因为会话双方“不认识”攻击者,攻击者不能提供合法的序列号;所以,会话劫持的关键是预测正确的序列号,攻击者可以采取嗅探技术获得这些信息。

    TCP协议的序列号 
    现在来讨论一下有关TCP协议的序列号的相关问题。在每一个数据包中,都有两段序列号,它们分别为: 
    SEQ:当前数据包中的第一个字节的序号 
    ACK:期望收到对方数据包中第一个字节的序号

    假设双方现在需要进行一次连接: 
    S_SEQ:将要发送的下一个字节的序号 
    S_ACK:将要接收的下一个字节的序号 
    S_WIND:接收窗口 
    //以上为服务器(Server) 
    C_SEQ:将要发送的下一个字节的序号 
    C_ACK:将要接收的下一个字节的序号 
    C_WIND:接收窗口 
    //以上为客户端(Client)

      它们之间必须符合下面的逻辑关系,否则该数据包会被丢弃,并且返回一个ACK包(包含期望的序列号)。 
    C_ACK <= C_SEQ <= C_ACK + C_WIND 
    S_ACK <= S_SEQ <= S_ACK + S_WIND

      如果不符合上边的逻辑关系,就会引申出一个“致命弱点”,具体请接着往下看。

    致命弱点 :
      这个致命的弱点就是ACK风暴(Storm)。当会话双方接收到一个不期望的数据包后,就会用自己期望的序列号返回ACK包;而在另一端,这个数据包也不是所期望的,就会再次以自己期望的序列号返回ACK包……于是,就这样来回往返,形成了恶性循环,最终导致ACK风暴。比较好的解决办法是先进行ARP欺骗,使双方的数据包“正常”的发送到攻击者这里,然后设置包转发,最后就可以进行会话劫持了,而且不必担心会有ACK风暴出现。当然,并不是所有系统都会出现ACK风暴。比如Linux系统的TCP/IP协议栈就与RFC中的描述略有不同。注意,ACK风暴仅存在于注射式会话劫持。

    TCP会话劫持过程 :
    假设现在主机A和主机B进行一次TCP会话,C为攻击者(如图2),劫持过程如下: 
    A向B发送一个数据包 
    SEQ (hex): X ACK (hex): Y 
    FLAGS: -AP--- Window: ZZZZ,包大小为:60

    B回应A一个数据包 
    SEQ (hex): Y ACK (hex): X+60 
    FLAGS: -AP--- Window: ZZZZ,包大小为:50

    A向B回应一个数据包 
    SEQ (hex): X+60 ACK (hex): Y+50 
    FLAGS: -AP--- Window: ZZZZ,包大小为:40

    B向A回应一个数据包 
    SEQ (hex): Y+50 ACK (hex): X+100 
    FLAGS: -AP--- Window: ZZZZ,包大小为:30

    攻击者C冒充主机A给主机B发送一个数据包 
    SEQ (hex): X+100 ACK (hex): Y+80 
    FLAGS: -AP--- Window: ZZZZ,包大小为:20

    B向A回应一个数据包 
    SEQ (hex): Y+80 ACK (hex): X+120 
    FLAGS: -AP--- Window: ZZZZ,包大小为:10

      现在,主机B执行了攻击者C冒充主机A发送过来的命令,并且返回给主机A一个数据包;但是,主机A并不能识别主机B发送过来的数据包,所以主机A会以期望的序列号返回给主机B一个数据包,随即形成ACK风暴。如果成功的解决了ACK风暴(例如前边提到的ARP欺骗),就可以成功进行会话劫持了。

     

    转载于:https://www.cnblogs.com/China-Waukee/p/9553336.html

    展开全文
  • 会话劫持防范

    2016-05-05 22:28:31
    会话劫持防范
  • 实验环境 ...CookieCadger   一键会话劫持 arpspoof        进行arp欺骗 CookieCadger简介     CookieCadger是一款cookie嗅探工具,可以劫持局域网中的cookie,重放流量。 Cook...

    实验环境

    攻击机kali   IP:192.168.3.147
    靶机win 7    IP:192.168.3.128

    工具

    CookieCadger   一键会话劫持
    arpspoof        进行arp欺骗

    CookieCadger简介

        CookieCadger是一款cookie嗅探工具,可以劫持局域网中的cookie,重放流量。

    CookieCadger的使用

    要求
    1.在JDK环境下运行;
    2.依赖tshark(一款命令行下的wireshark,kali中自带)

    1.CookieCadger不是kali自带的,首先下载CookieCadger
    CookieCadger下载地址:https://pan.baidu.com/s/1r4k2ea9poc7kG1C3NWNl5w 密码:3j7l
    下载下来的CookieCadger是一个jar包。

    root@afei:~/hack-tools# rz
    rz waiting to receive.
    root@afei:~/hack-tools# ls
    CookieCadger-1.08.jar
    root@afei:~/hack-tools# java -jar CookieCadger-1.08.jar 
    Exception in thread "AWT-EventQueue-0" java.lang.SecurityException: Prohibited package name: java.sql
    	at java.base/java.lang.ClassLoader.preDefineClass(ClassLoader.java:898)
    	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1014)
    	at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174)
    ...
    

    报错。原因:该jar包应该在jdk下运行,而kail自带的是openjdk
    解决办法:安装jdk8并进行相关配置

    (1)安装jdk并配置环境变量

    root@afei:~/hack-tools# rz
    rz waiting to receive.
    root@afei:~/hack-tools# tar -xzf jdk-8u191-linux-x64_\(1\).tar.gz -C /usr/local/
    root@afei:~/hack-tools# vim /etc/profile   #添加环境变量
    JAVA_HOME=/usr/local/jdk1.8.0_191
    PHTH=$JAVA_HOME/bin:$PATH
    CLASSPATH=$JAVA_HOME/jre/lib:$JAVA_HOME/lib/tools.jar
    export JAVA_HOME PATH CLASSPATH
    

    (2)通知系统java的位置

    root@afei:~/hack-tools# update-alternatives --install "/usr/bin/java" "java" "/usr/local/jdk1.8.0_191/bin/java" 1
    root@afei:~/hack-tools# update-alternatives --install "/usr/bin/javac" "javac" "/usr/local/jdk1.8.0_191/bin/javac" 1
    root@afei:~/hack-tools# update-alternatives --install "/usr/bin/javaws" "javaws" "/usr/local/jdk1.8.0_191/bin/javaws" 1
    update-alternatives: using /usr/local/jdk1.8.0_191/bin/javaws to provide /usr/bin/javaws (javaws) in auto mode
    root@afei:~/hack-tools# update-alternatives --install "/usr/bin/javaws" "javaws" "/usr/local/jdk1.8.0_191/bin/javaws" 1
    root@afei:~/hack-tools# 
    

    (3)设置JDK为默认java环境

    root@afei:~/hack-tools# update-alternatives --set java /usr/local/jdk1.8.0_191/bin/java
    update-alternatives: using /usr/local/jdk1.8.0_191/bin/java to provide /usr/bin/java (java) in manual mode
    root@afei:~/hack-tools# update-alternatives --set javac /usr/local/jdk1.8.0_191/bin/javac
    update-alternatives: using /usr/local/jdk1.8.0_191/bin/javac to provide /usr/bin/javac (javac) in manual mode
    root@afei:~/hack-tools# update-alternatives --set javaws /usr/local/jdk1.8.0_191/bin/javaws
    root@afei:~/hack-tools# 
    

    (4)重新载入profile

    root@afei:~/hack-tools# source /etc/profile
    root@afei:~/hack-tools# java -version
    java version "1.8.0_191"
    Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
    Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
    root@afei:~/hack-tools# 
    

    成功替换openjdk

    2.重新运行CookieCadger

    root@afei:~/hack-tools# java -jar CookieCadger-1.08.jar 
    java.io.FileNotFoundException: https://www.cookiecadger.com/files/plugins.zip
    	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1890)
    	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
    ...
    

    在这里插入图片描述
    在这里插入图片描述

    此时已经在监听192.168.3. 网段中的所有流量

    3.使用arpspoof进行arp欺骗

    root@afei:~# echo 1 > /proc/sys/net/ipv4/ip_forward
    root@afei:~# cat /proc/sys/net/ipv4/ip_forward
    1
    root@afei:~# arpspoof -i eth1 -t 192.168.3.128 192.168.3.2
    0:c:29:fa:a7:a3 0:c:29:3c:60:ad 0806 42: arp reply 192.168.3.2 is-at 0:c:29:fa:a7:a3
    0:c:29:fa:a7:a3 0:c:29:3c:60:ad 0806 42: arp reply 192.168.3.2 is-at 0:c:29:fa:a7:a3
    ...
    

    4.使用靶机win 7上网,截取流量
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    正在重新加载页面

    展开全文
  • 会话劫持后可以做什么操作by Ramesh Lingappa 通过拉梅什·林加帕(Ramesh Lingappa) 什么是会话劫持以及如何阻止它 (What is session hijacking and how you can stop it) This story is for beginners and anyone...

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

    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属性(或标志)( HttpOnlySecure )是这样做的原因。

    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/

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

    展开全文
  • TCP会话劫持

    2012-06-24 22:50:16
    会话劫持(Session Hijack)是一种结合了嗅探以及欺骗技术在内的攻击手段。广义上说,会话劫持就是在一次正常的通信过程中,黑客作为第三方参与到其中,或者是在数据流(例如基于TCP的会话)里注射额外的信息,或者是...
  • TCP会话劫持攻击

    千次阅读 2019-06-18 20:11:43
    TCP会话劫持攻击 【目的】 在本实验中,将在中间人攻击的基础上,进行TCP会话劫持攻击,通过实验实现 熟悉基于ARP欺骗的中间人攻击方式; 掌握TCP会话劫持原理。 【环境】 基于本书提供的实验环境,为了获得TCP...

     

    TCP会话劫持攻击

    【目的】

    在本实验中,将在中间人攻击的基础上,进行TCP会话劫持攻击,通过实验实现

    • 熟悉基于ARP欺骗的中间人攻击方式;
    • 掌握TCP会话劫持原理。

    【环境】

    基于本书提供的实验环境,为了获得TCP会话序列号并避免ACK风暴,攻击节点Kali通过ARP欺骗成为中间人,从而通过截获TCP数据包,对SeedUbuntu和OWASP之间的TCP会话进行劫持。

    【原理】

    TCP会话劫持目标是劫持通信双方已建立的TCP会话连接,假冒其中一方(通常是客户端)的身份,与另一方进行进一步通信。

    【步骤】

    注:这里的ip是测试环境的ip,自己做实验时需要替换成实验环境中的ip

    1.Kali节点利用ARP欺骗进行中间人攻击

    在Kali节点下,打开Kali节点的IP转发功能,如下所示:

    root@kali:~# cat /proc/sys/net/ipv4/ip_forward
    0
    root@kali:~# echo 1 > /proc/sys/net/ipv4/ip_forward
    root@kali:~# cat /proc/sys/net/ipv4/ip_forward
    1
    

    利用Ettercap工具执行以下命令:

    ettercap –G

    进入Ettercap的GTK图形界面方式,并选择“Sniff”菜单中的“Unified Sniff”选项,选择“eth0”作为嗅探监听接口,如下图所示:

    随后在“Hosts”菜单中选择“Scan for hosts”扫描局域网内攻击目标,并随后在菜单“Hosts list”中,选择Seed
    Ubuntu 192.168.200.124和OWASP192.168.200.125分别为target1和target2,如下图所示:

    选择菜单“MITM”中的“ARP poisoning”进行ARP欺骗,并选择“Sniff remote connections”,

    如下图所示:

    检查cat /proc/sys/net/ipv4/ip_forward 已经开启了转发;

    此时,在Seed Ubuntu和OWASP中执行arp –a命令显示MAC地址缓存,将发现ARP欺骗攻击已成功,其输入如下:

    root@ubuntu:/home/seed# arp -a
    ? (192.168.200.125) at 00:0c:29:da:ee:f6 [ether] on eth0
    ? (192.168.200.2) at 00:50:56:fc:e8:4b [ether] on eth0
    kali.local (192.168.200.10) at 00:0c:29:da:ee:f6 [ether] on eth0
    

    2.OWASP节点telnet到SeedUbuntu节点

    SeedUbuntu在默认端口23提供了telnet服务,在OWASP中执行

    telnet 192.168.200.124

    登陆到SeedUbuntu节点,输入用户名seed,密码为h4ndb00k(如果这里出现连接超时的情况,请在kali节点上确认ip转发功能是否开启,参照步骤一)。

    # telnet 192.168.200.124
    Trying 192.168.200.124...
    Connected to 192.168.200.124.
    Escape character is '^]'.
    Ubuntu 12.04.2 LTS
    ubuntu login: seed
    Password: 
    Last login: Sun Jan  3 01:21:43 PST 2016 from 192.168.200.125 on pts/11
    Welcome to Ubuntu 12.04.2 LTS (GNU/Linux 3.5.0-37-generic i686)
     * Documentation:  https://help.ubuntu.com/
    New release '14.04.1 LTS' available.
    Run 'do-release-upgrade' to upgrade to it.
    

    3.Ettercap截获TCP会话

    在Kali节点上,此时Ettercap(View-Connections)显示如下图所示,Ettercap已经获取了telnet的登陆用户名和密码。

    双击该会话连接(如果这里无法看到连接列表,依次点击【view -> connections】即可看到,请选择状态为active的一个会话连接进行下一步,如果这里没有,请在OWASP节点命令行随便输入一些内容,这时需要保证telnet连接没有断开,然后敲击回车),可进一步显示截获的数据,如下图所示:

    4.Ettercap 劫持TCP会话

    点击“Inject Data”,Kali节点作为中间人可以向TCP会话两端注入数据,如下图所示:

    此时,在Seed Ubuntu节点192.168.200.124上,通过Tcpdump抓包,可以看到以下数据:

    tcpdump -i eth0 '(tcp) and (host 192.168.200.125) and (not port 3389)' -X
    01:23:35.354602IP (tos 0x0, ttl 64, id 39021, offset 0, flags [none], proto TCP (6), length44)
        192.168.200.125.45991 >ubuntu.local.telnet: Flags [P.], cksum 0x27e2, seq 93:97, ack 409, win 32120,length 4
           0x0000: 4500 002c 986d 0000 4006 d013 c0a8 c87d E..,.m..@......}
           0x0010: c0a8 c87c b3a7 0017 bf79 97e9 698d 1005 ...|.....y..i...
           0x0020: 5018 7d78 0000 0000 6964 0a0a 0000      P.}x....id....
    

    即中间人Kali节点已经将命令注入到SeedUbuntu节点上。

    展开全文
  • 跨站实现HTTP会话劫持

    2016-12-06 16:00:05
    跨站实现HTTP会话劫持
  • 会话劫持-登录内网其它电脑帐号.exe
  • Sharp RDP Hijack是用于断开会话的概念验证.NET / C#远程桌面协议(RDP)会话劫持实用程序 背景 RDP会话劫持是一种开发后技术,用于控制(强制)断开的交互式登录会话。 在描述了该技术。 笔记 SharpRDPHijack.cs在...
  • 为了检测会话劫持,通过分析在路由节点上进行会话劫持的网络数据的RTT特征,用NS(network simulation)仿真了会话劫持过程,最后提出CRD(compare RTT detecting)方法,能够有效地检测到会话劫持攻击。
  • 内网会话劫持

    2018-07-11 09:48:00
    会话劫持 环境:一台kali虚拟机(攻击者,IP:192.168.41.140) 一台win7虚拟机(用户,IP:192.168.41.129) 网关IP:192.168.41.2 第一步 使用nmap扫描局域网内活动的主机,确定攻击目标,这里的192.168.41.129...
  • 会话劫持 会话劫持(Session hijacking),这是一种通过获取用户Session ID后,使用该Session ID登录目标账号的攻击方法,此时攻击者实际上是使用了目标账户的有效Session。会话劫持的第一步是取得一个合法的会话...
  • SSL会话劫持

    2017-04-18 17:52:24
    数据流重定向技术是SSL中间人监测的基础,该技术的使用使得被监测主机与SSL服务器的通信流量都会经过监测...故此必需使用SSL会话劫持技术,才能得到被监测主机与SSL服务器之间通信数据的明文。  自SSL问世以来,在其
  • 1,什么是会话劫持 在现实生活中,比如你去市场买菜,在交完钱后你要求先去干一些别的事情,稍候再来拿菜;如果这个时候某个陌生人要求把菜拿走,卖菜的人会把菜给陌生人吗?!当然,这只是一个比喻,但这恰恰就是...
  • arp欺骗和会话劫持

    千次阅读 2016-09-06 21:20:44
    arp欺骗以及会话劫持
  • kali局域网cookie会话劫持

    千次阅读 2019-05-11 21:19:13
    kali局域网cookie会话劫持 再次声明 小白一枚 小白一枚 小白一枚 原理: 利用抓包实现,重现流量,登录别人登录过的网站。 话不多说,开始 用到的工具:VM,kali,arpspoof ,tcpdump,ferrrt,hamster 第一步打开虚拟机...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 960
精华内容 384
关键字:

会话劫持