Web安全基础笔记

Web安全基础

web系统架构

web工作机制

万维网(World Wide Web)是一个由许多互相链接的超文本文档组成

Web的重要概念

1.资源:Web系统中对象称为资源

2.URI:统一资源标识符,用于标识一个资源(HTML文档、图片、视频片段)

3.URL:统一资源定位符(URI的一种子集)

4.HTTP:超文本传输协议,用于传输资源,使用者通过http来获得资源

Web站点架构

1586862379641

1586863001302

现实中大部分三部分

1.代理(公网IP)nginx-反向代理(实际用户访问的就是这个)

2.web程序 独立服务器

3.数据库 独立服务器

Web应用层次
  • 浏览器:FireFox/Chrome
  • Web前端框架:jQuery/Bootstrap/HTML5框架
  • Web应用:BBS论坛/CMS文章管理系统/BLOG博客
  • Web开发框架:Django/Rails/ThinkPHP/struts2
  • Web服务端语言:PHP/ASP/.NET/JAVA
  • Web容器:Apache/IIS/Nginx
  • 存储:数据库存储/内存存储/文件存储
  • 操作系统:Linux/Windows
Web安全问题根源

Web服务支撑软件(IIS、Apache、nginx、jboss、tomcat...)

Web开发框架(struts2、thinkphp..)

Web组件(openssl)

Web应用程序(php、jsp、.net)

Web客户端(IE、Firefox..)

Web传输协议(HTTP..)

http协议及burp基本使用

HTTP协议(超文本传输协议)

①一种通信协议,1990年提出,当前版本为HTTP/1.1

②使用超文本标记语言HTML将资源从服务器传送到客户端

③明文传输

超文本传输协议特点

①请求、响应模式

②简单快速:客户向服务器请求服务时,只需传输请求方法和路径。

③灵活:HTTP允许传输任意类型的数据对象。正在传输的类型有Content-Type加以标记。

④无连接:一个请求一个连接,完成后断开。

⑤无状态:协议对于事物处理没有记忆能力,在服务器不需要先前信息时应答较快。

注:比如转账前提需要登录账户,借助了cookie等技术不用再次登录。

HTTP协议结构

HTTP的一个会话,有Request请求和response相应组成

HTTP请求:

1.请求行:方法(),URI,协议/版本 Method-URL-Protocol/version

2.消息报头Request headers 请求头域

3.请求正文Entity body

HTTP响应

1.状态行:协议状态代码描述 Protocol-status code-Description

2.消息报头 response headers

3.响应正文 Entity body

1586785933100

HTTP请求方法

HTTP请求方法规定了客户与服务器联系的类型不同

HTTP1.1支持的7中请求方法

  • GET

  • POST

    以下基本都是调试中使用

  • HEAD拿头部内容

  • OPTIONS

  • PUT上传文件

  • DELETE删除文件

  • TRACE

    两种最常用的方法

    1. GET:把所有请求的数据都放在URL中,从URL中可以直接看到,但最大的传输信息量是2KB
    2. POST:把请求的数据放在请求的数据体中,在URL中不可见,长度不受限,常用于提交表单(把数据传给服务器,比如用户名密码)
HTTP请求URL

例 POST /servlet/default.jsp HTTP/1.1

URI

/servlet/default.jsp 表示一个URI地,URI指明了一个INTERNET资源。一个URI通常是相对于服务器的根目录被解释的,使用符号/开头

URL

HTTP URL(URL是一种特殊类型的URI,包含了用于查找某个资源的足够信息)的格式如下

http://host[":"port][abs_path]

HTTP请求头域

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

HTTP请求实体

例 LastName=Franks&FirstName=Michael

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

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

post方法请求实体,长度不显,URL中不可见,需要协助分析软件burpsuite

HTTP响应

HTTP响应

1.状态行:协议状态代码描述 Protocol-status code-Description

2.消息报头 response headers

3.响应正文 Entity body服务器返回的资源的内容

1586787946685

状态行: HTTP-Version Status-Code Reason-Phrase

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

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

Reason-Phrase表示状态大妈的文本描述

状态代码有三位数字组成,第一个数字定义了响应的类别,五中可能取值:

  • 1xx:指示信息--表示请求已接受,继续处理
  • 2xx:成功--表示请求已被成功接受 理解
  • 3xx:重定向--要完成请求必须更进一步的操作
  • 4xx:客户端错误--请求有语法错误或请求无法实现
  • 5xx:服务器端错误--服务器未能实现合法的请求
HTTP相应消息报头

相应消息报头允许服务器传递不能放在状态行的附加信息,这些域主要描述服务器的信息和Request-URI进一步的信息。响应头域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate

HTTP相应实体

Cookie技术与安全分析

Cookie机制
  • HTTP协议本身是无状态协议,HTTP不会记录前一次传输的数据信息,因此无法实现服务器和客户端的交互。
  • 如何实现HTTP会话的连续性,保持交互期间会话状态。

Cookie技术

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

Cookie的动机:用户身份跟踪与http会话管理。

  • 身份追踪:通过cookie标记访问用户身份
  • 购物车:可以为每个用户实现购物统计
  • 实现授权策略:认证用户通过cookie进行标记,通过cookie信息进行授权

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

Cookie的类型

会话cookie:是一种临时cookie,用户退出浏览器,会话cookie就会被删除了

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

Cookie的规范

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

cookie格式:

Set-cookie name|value|path|domain|expires

Set-Cookie:nolife=frodomain%3Dwww;path=/;domain=.51job.com;secure;httponly

  • cookiename:cookie变量的名称
  • value:赋予cookie的值
  • path:请求页面的路径
  • domain:cookie的作用范围(域名)
  • expires过期时间

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

Cookie的安全

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

针对cookie的攻击:

网络嗅探(中间人攻击):盗取cookie敏感信息

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

会话重放:通过盗取的cookie,进行会话重放攻击。

常见的web会话管理方式

1.cookie-based的管理方式

用户登录成功之后,把登录平整写到cookie里面,并给cookie设置有效期,后续请求直接验证存有登录凭证的cookie是否存在以及凭证是否有效,即可判断用户的登录状态。

1586865008665

2.基于server端的session的管理

服务器端session技术是用户第一次访问时,服务器就会创建的对象,并分配session存储空间。服务器为每一个session都分配一个唯一的sessionid,以保证每个用户都有一个不同的session对象。认证成功过,认证凭证计入到session存储空间中。1586865213385

注:与第一种区别于,第一种存储在客户端,第二种存在于服务器端,第一种包含敏感信息,第二种是id不包含敏感信息,可以凭借id找到凭证,第二种安全性更好。

1586865842824

3.token-based的管理方式

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

原文地址:https://www.cnblogs.com/c1047509362/p/12700857.html