渗透学习之web基础及安全分析

Web站点架构

1、应用程序的漏洞最多、最多种多样
2、中间件本身会出现漏洞，它是Web的基础设施，所以出现漏洞影响范围巨大

3、从传输角度来看，HTTP协议是明文协议，容易被嗅探从而获得信息，越来越多的使用HTTPS

4、浏览器网站本身可能会被“挂马”，被黑客嵌入了恶意链接，访问时触发定向到木马服务器并自动下载到本地，如果本地主机有漏洞则会被木马攻击，自动执行控制主机

5、Web应用程序、nginx代理、数据库各一台独立服务器，分散部署，可以减少被攻击

Web应用层次

浏览器：Firefox/IE/Chrome

Web前端框架：jQuery/Bootstrap/HTML5框架

Web应用：BBS/CMS/BLOG

Web开发框架：Django/Rails/ThinkPHP/struts2

Web服务端语言：PHP/ASP/.NET

Web容器：Apache/IIS/Nginx

存储：数据库存储/内存存储/文件存储

操作系统：Linux/Windows

从上到下数据输入，从下到上数据输出

Web安全问题根源
Web服务支撑软件问题：IIS、Apache、nginx、jboss、tomcat等

Web开放框架：structs2、thinkphp等

Web组件：openssl
Web应用程序：输入输出处理 php、jsp、.net等
Web客户端：IE、Firefox等
Web传输协议：HTTP

Web服务端软件安全问题

·软件自身安全漏洞

例：IIS 5.0超长URL拒绝服务漏洞、Unicode解码漏洞

·软件配置缺陷

默认账号、口令；不安全配置

例：IIS配置允许远程写入

Web程序安全问题

输入输出处理、会话控制、文件系统处理、用户访问机制、日志处理等

Web浏览器安全问题

可能存在安全漏洞（基于Cookie的攻击）

可能存在软件配置缺陷

Web协议安全问题(HTTP协议)

信息泄露：明文传输（用户名和口令向服务器提交的数据）

弱验证：简单的认证

缺乏状态跟踪：无状态协议、Session存在安全隐患

Web应用协议：HTTP
HTTP请求：
请求行：请求方法、地址、版本号等等
消息报头：接收的文本类型、语言、客户端代理、内容类型、Cookie等等
请求正文：传输的信息
请求的方法：
GET POST HEAD OPTIONS PUT DELETE TRACE

GET：把所有请求的数据都放在URL当中，从URL中可以直接看到，但最大传输的信息量是2 KB

POST：把请求的数据放在请求的数据体中，在URI中不可见，长度不受限，常用于提交表单

GET与POST最常用，向服务器提交表单数据用POST，GET一般是向服务器端获取数据，GET传输数据量受限制，而且暴露在URL中不安全

请求头域：

包含了一些有用的客户机环境的信息和请求的实体信息。比如，它可以包含浏览器使用的语言和实体的长度等等。每个请求包头都被CRLF（回车换行）序列所分离

HTTP请求实体

LastName=Franks&FirstName=Michael

以上是请求实体，在一个典型的HTTP请求中，这个实体可以变得更长。

Get方法请求实体，在url中可见，最大长度2KB

post方法请求实体，长度不限， URL中不可见，需要借助协议分析软件（burpsuite）

HTTP响应

包含三个部分：状态行、消息报头、响应正文

- 状态行：协议状态代码描叙

- 消息报头

- 响应正文服务器返回的资源的内容

HTTP响应状态行

▪ 状态行：HTTP-Version Status-Code Reason-Phrase

- HTTP-Version表示服务器HTTP协议的版本；

- Status-Code表示服务器发回的响应状态代码

- Reason-Phrase表示状态代码的文本描述。

▪ 状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：

- 1xx：指示信息--表示请求已接收，继续处理

- 2xx：成功--表示请求已被成功接收、理解、接受

- 3xx：重定向--要完成请求必须进行更进一步的操

- 4xx：客户端错误--请求有语法错误或请求无法实现

- 5xx：服务器端错误--服务器未能实现合法的请求

Cookie

Cookie，指某些网站为了辨别用户身份、进行session跟踪，而储存在用户本地终端上的数据

▪Cookie的动机：

用户身份跟踪与http会话管理。

- 身份追踪：通过cookie标记访问用户身份

- 购物车：可以为每个用户实现购物统计

- 实现授权策略：认证用户通过cookie进行标记，通过cookie信息进行授权

▪ 每个cookie都有一定的URL范围，客户请求这个范围的URL，都要提供这个cookie

Cookie的规范

Cookie由服务器端向客户端写入，包含在http响应头中的set-cookie字段

Cookie的格式

name：cookie变量的名称

value：赋予cookie的值

path：请求页面的路径

domain：cookie的作用范围（域名）

expires：过期时间

Cookie会被写入到客户端的internet temporary files文件夹内，当客户端请求域名范围内的URL时，会读取cookie文件，并在http请求头中的cookie字段

由服务端向客户端写入，包含在http响应头中的set-cookie中，把会话变得连续
Cookie类型
会话型：会话cookie是一种临时cookie，用户退出浏览器，会话Cookie就会被删除了

持久型：持久cookie则会储存在硬盘里，保留时间更长，关闭浏览器，重启电脑，通常是持久性的cookie会维护某一个用户周期性访问服务器的配置文件或者登录信息

Cookie安全属性
secure：设置了secure属性，浏览器只会在HTTPS和SSL等安全协议中传输此类Cookie。 

Httponly：设置了HttpOnly属性，javascript代码将不能操作cookie，可以防止xss脚本读取

Cookie安全

Cookie包含敏感认证信息以及cookie长时效时，存在较大安全风险。

▪ 针对cookie的攻击：

▪ 网络嗅探（中间人攻击）：盗取cookie敏感信息

▪ XSS跨站脚本攻击：可以盗取客户端cookie获取敏感信息

▪ 会话重放：通过盗取的cookie，进行会话重放攻击

常见Web会话管理的方式
1.cookie-based（基于cookie）的管理方式
2.基于server端session的管理
3.token-based（基于token）的管理方式

【cookie的目的只是把Web的会话变得连续，但是cookie里面有时候会包含敏感信息，然后用户的信息就会泄露，使得有机会被攻击】

cookie-based（基于cookie）的管理方式
用户登录后把凭证写到cookie里面，给cookie设置有效期，后续请求直接验证cookie的有效性，判断用户的登录状态，有效期过长导致重放，或者防守不严密有漏洞

基于server端session的管理

服务器端session技术是用户第一次访问时就会创建的对象，并分配session存储空间，为每一个session都分配一个id，即为sessionid，下次登录直接通过sessionid来找凭证如果空间里有session，即为有登录凭证

token-based（基于token）的管理方式

跟cookie-based的方式没有太多区别，只不过cookie-based里面写到cookie里面的ticket在这种方式下称为token，这个token在返回给客户端之后，后续请求都必须通过url参数或者是http header的形式，主动带上token，这样服务端接收到请求之后就能直接从http header或者url里面取到token进行验证

Openssl心脏滴血漏洞
问题出现在Openssl组件，组件存在一个漏洞，为这个服务器端针对这个插件发送特定的数据，会导致64KB内存的泄露 ，服务器内存信息包含数据交互的信息，如果有敏感信息，比如用户名和密码之类的信息，就会非常危险，例如session就会在服务器开一个内存空间存数据，存储用户的session，这个漏洞就会导致不安全