网络安全入门学习第六课——WEB安全基础2

p36273

已于 2023-07-01 23:14:54 修改

阅读量245

点赞数 2

分类专栏： web安全文章标签： web安全学习

于 2023-05-19 17:10:10 首次发布

本文链接：https://blog.csdn.net/p36273/article/details/130769614

版权

web安全专栏收录该内容

84 篇文章 82 订阅

订阅专栏

文章详细介绍了WEB访问流程，解释了Cookie和Session在跟踪用户状态中的作用，以及两者的区别。此外，讨论了同源策略在浏览器安全中的重要性，浏览器沙箱如何保护用户安全，以及恶意网站拦截的工作原理。最后，文章提到了OWASPTOP10安全风险，包括访问控制崩溃、敏感数据暴露等问题，强调了Web应用安全的重要性。

摘要由CSDN通过智能技术生成

一、WEB访问流程

在这里插入图片描述

二、Cookie/Session

1、Cookie

Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。比方：打开一个页面，输入账号密码，不小心操作失误，关闭了窗口，需要重新输入账号密码。要跟踪该会话，必须引入一种机制。

Cookie就是这样的一种机制。它可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。

Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

2、Session

除了使用Cookie，Web应用程序中还经常使用Session来记录客户端状态。Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。

Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

3、Cookie/Session的区别

1.session 在服务器端，cookie 在客户端（浏览器）。
2.session 默认被存在在服务器的一个文件里（不是内存）。
3.单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie
4.一般情况，登录信息等重要信息存储在session中，其他信息存储在cookie中

三、同源策略

同源策略（Same origin policy）：是由NetScape提出的一个著名的安全策略。所谓的同源，指的是协议，域名，端口相同。

浏览器处于安全方面的考虑，只允许本域名下的接口交互，不同源的客户端脚本，在没有明确授权的情况下，不能读写对方的资源。

它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。可以说Web是构建在同源策略基础之上的，浏览器只是针对同源策略的一种实现。
在这里插入图片描述

四、浏览器沙箱Sandbox

对于浏览器来说，采用 Sandbox 技术，无疑可以让不受信任的网页代码运行在一个受限的环境中，从而保护本地文件的安全。

浏览器的多进程架构，将浏览器的各个功能分开，当一个进程崩溃时，也不会影响到其他进程。

在现今的浏览器中，虽然有许多进程架构和 SandBox 保护，但浏览器所加载的一些第三方插件却往往不受 Sandbox 管辖，比如近年来 Pwn2Own 大会上被攻克的浏览器，往往都是因为第三方插件出现的安全漏洞导致的。Flash，PDF， .NetFramework 在近年来都成为浏览器攻击的热点。

五、恶意网站拦截

恶意网站拦截工作原理很简单，一般都是浏览器周期性的从服务器获取一份最新恶意网址的黑名单，如果用户上网时访问的网址存在于黑名单中，浏览器就会弹出一个警告页面。

常见的恶意网址分为两类：一类是挂马网站，这些网站通常包含有恶意的脚本如 Javascript 或 Flash，通过利用浏览器的漏洞，包括一些插件，执行 shellcode，在用户电脑植入木马；另一类是钓鱼网站，通过模仿知名网站的相似页面来欺骗用户。

六、OWASP TOP10

目前有3个版本OWASP Top 10，2021是最新的版本，2013和2017 的是之前两个版本。
在这里插入图片描述

1、访问控制崩溃

也就是我们常说的越权漏洞
未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据，例如：访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。

1.通过修改 URL、内部应用程序状态或 HTML 页面绕过访问控制检查，或简单地使用自定义的 API 攻击工具。
2.允许将主键更改为其他用户的记录，例如查看或编辑他人的帐户。
3.特权提升。在不登录的情况下假扮用户，或以用户身份登录时充当管理员。
4.以未通过身份验证的用户身份强制浏览的通过身份验证时才能看到的页面、或作为标准用户访问具有相关权限的页面、或API没有对POST、PUT和DELETE强制执行访问控制。

2、敏感数据暴露

很多Web应用程序和API都无法正确保护敏感数据，例如:财务数据、医疗数据和PII数据。攻击者可泄露容易受到破坏，因此，我们需要对敏感数据加密，这些数据包括:传输过程中的数据、存储的数据以通过窃取或修改未加密的数据来实施信用卡诈骗、身份盗窃或其他犯罪行为。未加密的敏感数据以及浏览器的交互数据。

3、注入

注入即是指web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的执行语句，在管理员不知情的情况下实现非法操作，以此来实现欺骗数据库服务器执行非授权的任意查询，从而进一步得到相应的数据信息。

所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意SQL命令目的的入侵行为。也就是说，我服务器明明想要你用户提交的是一个数据，可是你要么直接提交了一个命令，要么提交了一个数据之后，还在数据后面加上了一个命令。（夹带私货）

4、不安全的设计

4.1、漏洞产生原因

在开发软件时，在关键身份验证、访问控制、业务逻辑和关键流部位没有进行安全的设计。
由于开发过程中的设计缺陷，可能导致注入、文件上传等漏洞被利用；

4.2、业务逻辑的显性体现

1、支付逻辑
2、密码找回
3、验证码暴力破解
4、验证码重复使用
5、验证码客户端回显
6、验证码绕过
7、验证码自动识别

4.3、支付逻辑漏洞

所有涉及购买、支付等方面的功能处就有可能存在支付漏洞
挖掘：寻找网站的支付系统、或兑换系统，抓包判断有没有敏感信息可以修改。

利用：

1、修改支付价格
2、修改支付状态
3、修改购买数量
4、修改优惠卷、积分
5、修改支付接口
6、多重替换支付
7、重复支付
8、最小额支付
9、最大额支付问题
10、无限制试用

5、安全配置不当

安全配置错误是最常见的安全问题，这通常是由于不安全的默认配置、不完整的临时配置、开源云存储、错误的 HTTP 标头配置以及包含敏感信息的详细错误信息所造成的。

因此，我们不仅需要对所有的操作系统、框架、库和应用程序进行安全配置，而且必须及时修补和升级它们。

可能出现的风险点

1、应用程序启用或者安装了不必要的安全功能
2、默认账户名和密码没有修改
3、应用软件已过期或出了新版本未更新
4、应用程序服务器，应用程序框架等未进行安全配置。
5、错误处理机制披露大量敏感信息
6、对于更新的系统，禁用或不安全地配置安全功能。

6、使用含有已知漏洞组件

组件(例如:库、框架和其他软件模块)拥有和应用程序相同的权限。

如果应用程序中含有已知漏洞的组件被攻击者利用，可能会造成严重的数据丢失或服务器接管。同时，使用含有已知漏洞的组件的应用程序和API可能会破坏应用程序防御、造成各种攻击并产生严重影响。

7、认证崩溃

通常，通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌，或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。

在开发web应用程序时，开发人员往往只关注Web应用程序所需的功能，所以常常会建立自定义的认证和会话方案。但是要正确的实现这些方案却是很难的。结果就在退出、密码管理、超时、密码找回、帐户更新等方面存在漏洞。
也就密码等重要数据进行交互的时候，程序存在了问题，并且被利用了。

可能出现的风险点

1、允许暴力破解密码或者账号。
2、允许默认的、弱的或众所周知的密码，例如“admin/123456”或 “admin/admin”。
3、使用明文、加密或弱散例密码。
4、缺少或失效的多因素身份验证。
5、暴露URL中的会话ID(例如URL重写)。
6、旧密码泄露
7、会话ID使用时间过长

8、软件和数据完整性失败

软件和数据完整性故障与不能防止完整性违规的代码和基础设施有关。一个例子是应用程序依赖来自不受信任的来源、存储库和内容交付网络 (CDN) 的插件、库或模块。不安全的 CI/CD 管道可能会导致未经授权的访问、恶意代码或系统受损。最后，许多应用程序现在包括自动更新功能，其中更新在没有充分完整性验证的情况下被下载并应用于以前受信任的应用程序。攻击者可能会上传自己的更新以分发并在所有安装上运行。另一个例子是对象或数据被编码或序例化为攻击者可以看到和修改的结构，容易受到不安全的反序例化。