Web安全防护

2024-01-08 20:32:03

一、Web安全简介

二、Web攻击来源

1、客户端:

2、服务器:

3、通道:

三、Web应用基本组成部分

URL工作过程

HTTP/HTTPS

HTTP有两类报文

HTTP请求报头

HTTP协议请求方法

状态码

状态码组成

三、Cookie概述

Cookie和Session的关系

四、Web攻击

1、注入漏洞

SQL注入步骤

2、跨站脚本

基本跨站类型

3、跨站请求伪造

跨站请求伪造攻击原理

五、Web安全防御手段

1、从Web架构上防御:行为规范

2、从Web语音上防御:Web应用系统防御/入侵检测

3、从通信通道上防御:Anti-DDos

六、URL地址结构

URL过滤原理

URL过滤总体流程

七、恶意URL来源

恶意URL检测控制

八、Web信誉体系应用场景

Web信誉体系工作流程

Web信誉体系分类

Web应用系统安全缺陷

1、程序设计安全隐患:

2、配置管理安全隐患:

3、运行平台安全漏洞:

九、WAF工作流程

WAF处理架构

十、DDOS&CC攻击

十一、X-Forwarded-For


一、Web安全简介

web安全简介:传统网络层面的攻击与防御手段都日趋成熟,随着应用市场的爆炸性发展,基于Web的应用也逐渐增多。在此背景下Web应用更是成为了黑客瞄准的重要目标。

二、Web攻击来源

Web的攻击来源,主要可以根据Web应用的实现机制,从以下三个方面来探讨。

1、客户端:

  • 网站木马
  • 钓鱼欺骗
  • 活动内容攻击

2、服务器:

  • web服务器的漏洞
  • 授权、认证攻击
  • 跨站脚本攻击
  • SQL注入

3、通道:

  • Dos、CC攻击
  • 窃听
  • SSL重定向

三、Web应用基本组成部分

Web基于客户端(client)/服务器(Server)架构实现,包含三个部分:

  • 使用HTML (HyperText Mark-up Language) 描述文件
  • 使用URL(Uniform Resource Locator) 指定文件的所在
  • 透过HTTP (HyperText Transfer Protocol) 协议与服务器沟通

对一个网站进行渗透测试:

1、手机信息:

ping网站解析ip地址(大型的网站都部署有CDN【加速访问】,就近访问,网站源在深圳,北京有站点缓存,北京用户有限访问北京这边),普通ping基本都是CDN的地址。

URL工作过程

URL连接可以执行JavaScript代码

HTTP/HTTPS

  • HTTP(Hypertext Transfer Protocol)是一种无状态的协议,基于简单的请求-响应模式 (requests/responses)

HTTP有两类报文

  • 请求报文一从客户端向服务器发送请求报文
  • 响应报文一从服务器到客户端的回答

HTTP包:请求(GET获取路径)和响应(Replay)

HTTP请求报头

  • 一个HTTP请求报文由请求行(request line)、请求头部(header)、空行和请求数据4个部分组成。

请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成,它们用空格分隔。例如,GET /index.html HTTP/1.1.

HTTP协议请求方法

HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。

  • GET:读取由URL所标识的信息。
  • OPTION:请求一些选项的信息。
  • HEAD:请求读取URL所标识信息的首部。
  • POST:给服务器添加信息。
  • PUT:在指明的URL下存储一个文档。
  • DELETE:删除指明的URL所标志的资源。
  • TRACE:用来进行环回测试的请求报文。
  • CONNECTHTTP:用于代理服务器。

状态码

所有HTTP响应的第一行都是状态行,依次是当前HTTP版本号,3位数字组成的状态代码,以及描述状态的短语,彼此由空格分隔。

格式为:HTTP-Version Status-Codeeason-Phrase CRLF。

如: HTTP/1.1200 OK。其中HTTP-Version表示服务器HTTP协议的版本。

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

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

状态码组成

状态代码由三位数字组成,第一个数字定义了向应的类别,且有五种可能取值。

  • 1xx:信息--表示请求已接收,继续处理。
  • 2xx:成功--表示请求已被成功接收、理解、接受。如:200 0K,请求成功。
  • 3xx:重定向--要完成请求必须进行更进一步的操作。
  • 4xx:请求错误--请求有语法错误或请求无法实现。
    • 如:400 Bad Request,客户端请求有语法错误,不能被服所理解。
    • 403 Forbidden,服务器收到请求,但是拒绝提供服务。
    • 404 Not Found,请求资源不存在。
  • 5xx:服务器端错误--服务器未能实现合法的请求。
    • 如:503 Server Unavailable,服务器当前不能处理客户端的请求。

三、Cookie概述

Cookie是一种在客户端保持HTTP状态信息的技术,由Web服务器将其携带在响应报文中发送给客户端浏览器。

Cookie和Session的关系

浏览器存放Cookie,服务器存放Sessioon ID。

用户请求使用Session页面时,Web服务器产生Session和一个Session-id并返回临时Cookie (Key=sessionid)。

用户第二次请求Session页面会自动带上Cookie信息,Web服务器接收请求并通过Sessionid读取Session,把信息返回用户。

SessionID是保存到客户端,用Cookie保存的,用户提交页面时,会将这一SessionID提交到服务器端,来存取Session数据。这一过程,是不用开发人员干预的。所以一旦客户端禁用Cookie那么Session也会失效。

Cookie是保存在客户端的,Session是保存在服务器端的。

Cookie是保存在客户端的,这导致了Cookie的不可靠性。而Session虽然保存在服务器端,但由于用户会获得Session的一个标记,称为Sessionid,这个id是用Cookie保存的,这导致了Session的不安全性。同时通过一些抓包工具也可以达到盗用Session的目的。

为了提高Session的安全性和Cookie的可靠性,可以给它们设置过期,增加签名内容,同时可以限制用户IP。

OWASP开源Web应用安全项目,一个组织,发布web安全的漏洞。

需要重点关注的三个攻击:

  • 注入
  • 跨站脚本(XSS)
  • 跨站请求伪造(CSRF)

四、Web攻击

1、注入漏洞

注入漏洞发生在应用程序将不可信的数据发送到解释器时。注入漏洞的本质就是混淆数据和执行代码,使输入的数据变成可执行的语句。

其中,SQL注入攻击是最常见、危害最严重的注入攻击。

注入能导致数据丢失(注入dele删除)或数据破坏(数据覆盖操作)、缺乏可审计性或是拒绝服务。注入漏洞有时甚至能导致完全主机接管(注入反向TCP代码,控制服务器)

攻击者提供一段代码给服务器比如把code和date数据进行发送,服务器进行计算,不小心执行了。

构建特殊语句,使数据库执行

数据库返回值:

SQL注入步骤

  • 判断是否存在注入漏洞:比如and 1=1,or'1'=1等。
  • 数据库类型判断:'单引号、;--一个分号两个横线。
  • 获取数据库数据或Dump整个数据库。
  • 提权:and exists(select count(*)from)

2、跨站脚本

跨站脚本(xSS)是近年来最为流行的网络攻击方式之一,已经占到了网络攻击相当大的比例,众多网站,如著名的Facebook等都遭遇过此类攻击。国内知名的新浪微博遭遇的网络病毒实际上也是跨站脚本漏洞所导致的。

从本质上看,跨站脚本实际上是一种恶意代码执行的方式。主要原因在于网站对于用户提交的数据过滤不严格,导致问题产生。

基本跨站类型

  • 反射型
  • 存储型

XSS起初的危害主要是盗取用户的Cookie信息。Cookie信息中包含了浏览者和网站服务器之间的常用记录,包括登录记录、浏览记录等。如果攻击者得到了用户的Cookie信息,可以模仿用户和网站进行交互,得到更多想要的数据。例如,攻击者在某论坛上发布一个URL链接,当用户点击该链接后,用户的浏览器就会将Cookie信息发送到攻击者的网站。攻击者收集到Cookie信息后可以以浏览者身份访问网站、进入邮箱等,继续窃取私人信息。

跨站脚本简称为CSS(Cross Site Scripting),因为容易和另一个名“层叠样式表”(Cascading Style Sheets.CSS)混淆,为了区别,网络安全人士习惯将其简称为XSS攻击。

反射型:跨站代码一般存在于链接中,请求这样的链接时,跨站代码经过服务端反射回来,这类跨站的代码一般不存储到服务端。

反射型跨站脚本攻击实例

3、跨站请求伪造

CSRF(Cross-site request forgery)跨站请求伪造,也被称成为oneclick attack或者session riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本 (XSS),但它与XSS非常不同,并且攻击方式几乎相左。XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。

用户登录真站产生Cookie,然后不登录出真网站的情况下,弹出一个弹窗点击后进行302重定向到黑客网站。

跨站请求伪造攻击原理

五、Web安全防御手段

1、从Web架构上防御:行为规范

  • URL过滤规范上网行为
  • Web信誉体系防范恶意网页站点

2、从Web语音上防御:Web应用系统防御/入侵检测

  • 针对服务器端漏洞、数据库防御
  • 防范跨站脚本等类型攻击

3、从通信通道上防御:Anti-DDos

  • 防范HTTP-Flood攻击

六、URL地址结构

URL过滤原理

URL过滤总体流程

七、恶意URL来源

  • 沙箱联动场景沙箱检测到恶意URL。
  • AV检测到的带恶意文件的URL。
  • 低信誉URL。

恶意URL检测控制

  • URL配置文件的恶意URL检测开关开启时依次检测上述恶意URL。

八、Web信誉体系应用场景

  • Web信誉用于描述网站的可信程度,信誉度高的网站上文件的安全性也高。FW根据网站信誉度的高低,决定是否提取出网络流量中的文件并进行威胁检测。
  • URL信誉反映了用户访问的URL是否值得信赖。
  • 利用远程查询服务获取URL的信誉值,并对低信誉的URL实施阳断。

Web信誉体系工作流程

Web信誉体系分类

按照不同的信誉度,Web信誉功能将网站分为4类

  • 预定义可信网站
  • 自定义可疑网站a
  • 自定义可信网站0
  • 未知网站

Web应用系统安全缺陷

1、程序设计安全隐患:

  • 不安全的用户访问处理机
  • 不安全的数据验证机制
  • 不安全的系统边界防护机制
  • 程序编写安全缺陷

2、配置管理安全隐患:

  • 服务器配置管理安全缺陷
  • 数据库配置管理安全缺陷
  • 发布平台配置管理安全缺陷
  • 应用自身配置管理安全缺陷

3、运行平台安全漏洞:

  • 应用服务器安全漏洞
  • 数据库管理系统安全漏洞
  • 发布平台安全漏洞

九、WAF工作流程

WAF主要由执行前端、后端中心系统及数据库组成。

WAF处理架构

协议重组:WAF绕过,HTTP包允许GET内容拆成N个包,最后组起来就是一个注入攻击。

十、DDOS&CC攻击

CC攻击:一个网站有多个资源,每个人看到资源都不一样,黑客伪装无穷多ID号去获取资源,服务器去根据ID号查,数据库没有这个人,不停返回ID错误,数据库被耗死,新的人进来由于数据库忙碌没法提供服务(无穷的访问请求)

CC攻击是指利用大量代理服务器对目标计算机发起大量连接,导致目标服务器资源枯竭造成拒绝服务,和传统的网络层DDOS攻击方法的不同的是,CC攻击一般针对WEB页面进行攻击,首先黑客会寻找比较耗费服务器资源的页面,然后使用代理将CC攻击转发到服务器,由于服务器接收到大量CC攻击,而造成服务服务器资源枯竭,从而造成拒绝服务,CC攻击危害十分大,严重影响网站的正常运行。

CC攻击防护基于用户单位时间内发起请求的页面和请求数进行统计,当WAF发现单个客户端在一定时间内发起非正常页面请求次数,将该客户端锁定至黑名单中一定时间,从而达到CC攻击的防御。

高速缓存&防篡改技术:提前缓存比如图片这种素材,即使黑客把网站原始素材改了,后边的人要访问这个素材,直接从缓存里边给到。

双向SSL

基于HTTPS的应用系统,在网络环境常规的设备无法识别传输的应用数据,更无法识别来自应用层的攻击。要对HTTPS应用进行应用防护,必须要求WAF能良好的支持HTTPS协议并能对SSL数据流进行中继。

有了地址组和端口组,我们可以把一个部门所有主机的IP地址定义到一个地址组中,或把一类服务加入端口组中

实现功能

  • 需要导入的证书
  • 实现HTTPS双向代理接入,无需改变网络。

十一、X-Forwarded-For

SSL下源IP解析(X-Forwarded-For)

在某些复杂环境可能会经过多层代理,每次代理后都会把转换前的IP加在X-Forwarded-For头部。

X-Forwarded-For格式如下:X-Forwarded-For:cient1,proxy1,proxy2。

如头部为X-Forwarded-For:115.238.8.8,192.168.1.1那么在反向代理级数选1的情况下,日志显示的源IP为192.168.1.1;如果配置为2则显示115.238.8.8。

X-Forwarded-For起到的作用就是标明经过代理来这里(可能有多次代理,字段中就会有多个),你回的时候也要经过代理回去,保持来回路径一致。

文章来源:https://blog.csdn.net/qq_45022073/article/details/135414933
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。