web应用安全之HTTP与会话管理总结

HTTP

  状态码 

  状态码：200（成功）301，301（重定向）404（找不到资源）500（服务器错误）

  Referer

  Referer头信息告诉我们请求是从那个页面链接过来的，是URL。但是Referer头信息可能成为问题之源。Referer头信息可以由访问者本人通过Fiddler之类的工具修改，所以未必会显示正确的连接。

  比如URL中包含的会话ID通过Referer泄露给外界，可能会使自己的身份被他人冒名顶替。

  URL中包含重要信息时，就有被Referer头信息泄密的风险。

  GET与POST

  GET仅用于查阅，没有副作用（指更新删除追加等操作）。发送敏感数据时用POST。

  hidden参数

  在fiddler的Rules下automatic breakpoints中before requests截取请求信息并修改。

  浏览器发送的值都能被修改。

  

COOKIE会话管理

  Cookie相当于服务器下达给浏览器的命令。记忆应用程序的状态的功能叫做“会话管理”。

  因为Cookie能保存的值的数量和字符串长度有限，并且Cookie的值被用户自己看到或更改，所以不适用于存储敏感信息。

  可以采用在Cookie中保存类似于“受理编号”的会话ID，实际的值保存在服务器端的方法。这就叫做“使用Cookie的会话管理”。

  会话ID应该满足如下要求

  1.不能被第三方推测

  2.不能被第三方劫持

  3.不能向第三方泄露

 使用开发工具提供的会话管理机制。

 认证之后改变会话ID，防止被劫持。

  会话ID泄露原因

  发行Cookie时的属性指定有问题

  会话ID在网络上被监听

  安全隐患如跨站脚本

  PHP或浏览器平台安全隐患

  会话ID保存在URL中，通过Referer头信息泄露

  

  Cookie属性设置

  Domian Cookie发送对象服务器的域名

  Path Cookie发送对象URL的路径

  Expires Cookie的有效期限。未指定则表示至浏览器关闭为止

  Secure 仅在SSL加密情况在发送Cookie

  HttpOnly 指定此属性的Cookie不能被Javascript访问

  Domian

  指定Domain=example.com则Cookie被发送到a.example.com和b.example.com，而不会被发送到c.example.org。

  未指定Domain时，Cookie只能发送到生成它的服务器，换言之，未指定时发送的范围就越小，越安全。

  举例：假设example.com是服务器租赁商，a.example.com和b.example.com都是架设在此服务器上的网站，如果a.example.com指定Cookie

中Domain=exmaple.com，此Cookie就会被泄漏至b.example.com。

  原则上不设置Domain属性。

  

  Cookie Monster Bug

  举例，网站域名为a.com.cn，则生成域名中最短为a.com.cn，但是一些就浏览器域名却指定为com.cn，就导致可能会泄露至任意域名为com.cn的网站中。

  使用地域性域名的网站，在加强会话固定攻击的同时，可以考虑迁移至其他形式的域名。