web核心-http协议
上一篇 /
下一篇 2016-04-19 16:18:42
/ 个人分类：web测试
http协议简介：超文本传输协议，所有在网页中展现的内容都叫超文本，应用层协议，本层协议脱离了物理层tcp/ip，只考虑传输的内容本身
主要特点如下：
1.明文传输，安全性差，
2.无状态的协议，但是通过session和cookie来解决了这个问题，单纯来说，服务器端不会去保存你登录的状态什么的，需要你客户端不断的输入用户名密码之类的，但是我们实际却从来没遇到过这样的问题，那是因为html通过session和cookie来解决了这个问题
3.应用层协议，标准化，1.1版本，
其中1和2点比较重要，很多问题都是基于这两点引发的，
测试的时候针对这种特色去设计用例
请求和响应：
请求：
常用：
post：投递，提交的用户名，密码，帖子，文件上传，填写的一些表单内容之类
需要了解的：
HEAD 请求获取由Request-URI所标识的资源的响应消息报头
PUT 请求服务器存储一个资源，并用Request-URI作为其标识
DELETE 请求服务器删除Request-URI所标识的资源
TRACE 请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT 保留将来使用
OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求
说一下head：该方法与get方法几乎一样，对于head请求的回应部分来说，它的http头部包含的信息与通过get请求得到的信息几乎是一样的，但是利用这个方法你不必传输整个资源的内容，就可以得到Request-URI所标识的资源的信息，这个方法就主要用来测试超链接的有效性，是否可以访问，以及最近是否更新
响应状态：
状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：
1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
3xx：重定向--要完成请求必须进行更进一步的操作
4xx：客户端错误--请求有语法错误或请求无法实现
5xx：服务器端错误--服务器未能实现合法的请求
常见状态代码、状态描述、说明：
200 OK //客户端请求成功
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden //服务器收到请求，但是拒绝提供服务
404 Not Found //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常
eg：HTTP/1.1 200 OK （CRLF）
Http Session:
session：解决了http无状态的问题，用来
记录浏览器或者客户端的状态用的，通过session把这个连接状态保存起来了，
session ID：一个32位长度的16进制编码，服务器给的，你做的任何事情都和我服务器给你的这个id挂钩，就这样让一个状态标记出来了，它是一个重复几率很小的身份标识而已，唯一的表示当前客户端的一个身份，
服务器如何通过session机制保存对应的状态呢？
服务器端保存了这个session-id对应的文件，通过文件里面的内容，还有id，三个共同完成了状态的保持
有什么问题：
一个大型网站，访问的人很多，每一个都有对应的用户名密码，每一个都要在服务器上建立一个自己的sesssion文件，几十万个用户对应几十万个文件，这个文件的读取，本身数目，搜索，管理都是瓶颈，就不太可能用一个个的session文件去存放管理了，那么有什么解决方式？1.把这些文件都放在内存中而不是硬盘里，因为不需要一直存在，而且内存处理速度比硬盘块多了 2.使用关系型
数据库来维护，几十万个数据放数据库来搞，就各种效率高了哈，这就是所谓性能优化，没有太多高大上，主要就是各种细节，各种细节做好了，设计好，整体性能就起来了
http-cookie:
cookie:由服务器生成，保存在客户端的，解决了我想在客户端保存一些东西方便我下次直接登录，原理就是：浏览器从客户端读出cookie，然后发送给服务器，服务器验证该状态ok，于是服务器响应操作给客户端。
所以在我们平时所用的一些网站中记住只有点退出，才是把cookie清空，注销，下次才是一个全新的请求，不能直接点叉叉。cookie没有清除，就有安全隐患。
补充一点关于安全性测试的一点东西：
session ID和cookie的欺骗漏洞：session我们都知道是一个随机生成的id，产生的问题就是你把它这个id获取到，得到验证就ok了，就能够得到一些状态，而cookie也是一样，虽然你有可能在加密了，在客户端的cookie文件中不是明明白白的登录名和密码，但是你只要获取到它的密文，就是加密后生成的东西，你把这个东西发给服务器端，服务器照样也会相应你，这就是所谓的欺骗，和街边**证的一样
看fiddler的使用：
它主要是针对客户端发送请求的截获，编好了重新发给服务器，就是按我们自己的意愿去**一些请求，直接用编程语言去开发一个发送http请求的代码，也可以达到这样的目的。实现
自动化测试的目的，通过代码去抽取一些值，也就是现在很多安全性工具实现的原理，webinspec，
fiddler的原理其实就是利用了session，cookie的欺骗漏洞来做，我看到的test case有两个：
1.模拟用户登录，验证一些信息，比如我截获了post回话并重新编写，在里面修改了密码，或用户名，得到什么样的信息，成功还是错误，是对登录状态并提示的一个验证
2.获取seesion id和cookie id去得到服务器的响应
收藏
举报
TAG:
