【信息安全原理】——Web应用安全（学习笔记）

最新推荐文章于 2024-08-09 11:42:08 发布
最新推荐文章于 2024-08-09 11:42:08 发布
阅读量1.1k 收藏 24
点赞数 18
文章标签： 前端 安全 学习
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ZL_1618/article/details/136166976
版权

📖
前言：Web是互联网上最为典型的应用模式，几乎涉及人们生活的各个方面，因此其安全问题备受关注。本章我们首先聚焦Web应用本身的安全问题，包括：Web应用体系的脆弱性分析，典型Web应用安全漏洞攻击（SQL注入、XSS、Cookie欺骗、CSRF、目录遍历、操作系统命令注入、HTTP消息头注入等）及其防范措施，然后简要介绍安全的HTTP协议HTTPS。

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/c47cd92c87cd4baa815b771e11dadf03.png)

目录
  • 🕒 1. Web应用体系结构脆弱性分析
  • * 🕘 1.1 Web应用安全
    • 🕘 1.2 HTTP协议安全问题
    • 🕘 1.3 Cookie的安全问题
  • 🕒 2. 常见Web应用攻击及防范
  • * 🕘 2.1 SQL注入攻击及防范

    •   * 🕤 2.1.1 SQL注入原理
      • 🕤 2.1.2 SQL注入攻击流程
      • 🕤 2.1.3 SQL注入检测
      • 🕤 2.1.4 实验：SQL注入
    • 🕘 2.2 跨站脚本（XSS）攻击及防范
    •   * 🕤 2.2.1 工作原理
      • 🕤 2.2.2 反射式XSS
      • 🕤 2.2.3 储存式XSS
      • 🕤 2.2.4 DOM式XSS
      • 🕤 2.2.5 防御XSS
      • 🕤 2.2.6 实验：XSS攻击
    • 🕘 2.3 Cookie欺骗及防范
    •   * 🕤 2.3.1 伪造Cookie信息
      • 🕤 2.3.2 监听Cookie来实现会话劫持
    • 🕘 2.4 CSRF攻击及防范
    • 🕘 2.5 目录遍历及其防范
    • 🕘 2.6 操作系统命令注入及防范
    • 🕘 2.7 HTTP消息头注入攻击及防范
    • 🕘 2.8 其他攻击
    •   * 🕤 2.8.1 恶意文件执行
      • 🕤 2.8.2 不安全的直接对象引用
      • 🕤 2.8.3 信息泄露和不当的错误处理
      • 🕤 2.8.4 认证和会话管理不完善
      • 🕤 2.8.5 不安全的加密存储
      • 🕤 2.8.6 URL访问缺少限制
  • 🕒 3. HTTPS
  • * 🕘 3.1 提出背景：不安全的通信
    • 🕘 3.2 防御

🕒 1. Web应用体系结构脆弱性分析

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/30e3479971c14da5a66a4c6a6b43546c.png)
Web应用体系结构潜在弱点：

  • Web客户端
    • 活动内容执行，客户端软件漏洞的利用，交互站点脚本的错误
  • 传输
    • 偷听客户-服务器通信，SSL重定向
  • Web服务器
    • Web服务器软件漏洞；
  • Web应用程序
    • 攻击授权、认证、站点结构、输入验证，以及应用程序逻辑
  • 数据库
    • 通过数据库查询运行优先权命令，查询操纵返回额外的数据集。

🕘 1.1 Web应用安全

Web应用程序功能与安全隐患的对应关系

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/4672a26e6cb34c4c931bbea85dd426d9.png)

🕘 1.2 HTTP协议安全问题

HTTP协议是一种简单的、无状态的应用层协议（RFC1945、RFC2616）

  • 无状态使攻击变得容易
  • 基于ASCII码，无需弄清复杂的二进制编码机制，攻击者就可了解协议中的 明文信息
  • 互联网中存在的大量中间盒子，HTTP标准(RFC 2616和RFC 7320)的理解如果不一致，就有可能导致一些新的攻击发生

常见安全问题：

  • HTTP会话经常被劫持
    ![在这里插入图片描述](https://img-
    blog.csdnimg.cn/direct/bbd9953de2914f14a91e674ce2d850d5.png)

  • HTTP会话头泄露隐私信息
    ![在这里插入图片描述](https://img-
    blog.csdnimg.cn/direct/b4068806261144978bca03f94641fa46.png)

  • 中间盒子带来的HTTP安全问题

🔎 端到端通信中危险的中间盒子：祝福还是诅咒？

🕘 1.3 Cookie的安全问题

为什么需要Cookie？

  • 解决无状态问题 ：保存客户服务器之间的一些状态信息
  • Cookie是指网站为了辨别用户身份、进行会话跟踪而储存在用户本地终端上的一些数据（通常经过编码），最早由网景公司的Lou Montulli在1993年3月发明的，后被采纳为RFC标准（RFC2109、RFC2965）

Cookie的生成与维护：

  • 由服务器端生成，发送给客户端（一般是浏览器），浏览器会将Cookie的值保存到某个目录下的文本文件内，下次请求同一网站时就发送该Cookie给服务器（前提是浏览器设置为启用Cookie）
  • 服务器可以利用Cookie存储信息并经常性地维护这些信息，从而判断在HTTP传输中的状态
  • Cookie在生成时就会被指定一个Expire值，这就是Cookie的生存周期。到期自动清除
  • 如果一台计算机上安装了多个浏览器，每个浏览器都会在各自独立的空间存放Cookie
  • Cookie中的内容大多数经过了编码处理

Cookie的一般格式如下：
NAME= VALUE; expires= DATE; path= PATH;
domain= DOMAIN_NAME; secure

示例
autolog = bWlrzTpteXMxy3IzdA%3D%3D;
expires=Sat, 01-Jan-2018 00:00:00 GMT; path=/;
domain=victim.com

Cookie中包含了一些敏感信息，如用户名、计算机名、使用的浏览器和曾经访问的网站等，攻击者可以利用它来进行窃密和欺骗攻击

🕒 2. 常见Web应用攻击及防范

OWASP（开放式Web应用程序安全项目）是一个开放的社区，由非营利组织
OWASP基金会支持的项目。对所有致力于改进应用程序安全的人士开放，旨在提高对应用程序安全性的认识。
其最具权威的就是“10项最严重的Web 应用程序安全风险列表”
，总结并更新Web应用程序中最可能、最常见、最危险的十大漏洞，是开发、测试、服务、咨询人员应知应会的知识。

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/acb80ce95efe467199afd307f7873645.png)
![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/13a9dc96b7b74703b58251cad90485a9.png)

🕘 2.1 SQL注入攻击及防范

定义：注入漏洞，特别是SQL注入，在Web应用程序中很常见。注入发生在用户提供的数据作为命令或查询的一部分发送到解释器时。攻击者的恶意数据欺骗解释器执行意外的命令或更改数据。

最普遍的注入漏洞包括：

  • SQL注入：通过SQL语句恶意地调用后台数据库
  • 系统调用
  • 通过shell命令调用外部程序
🕤 2.1.1 SQL注入原理

例子：

  • 通过用户提供的参数来查询表中的数据
  • "SELECT * FROM USERS WHERE SSN=‘" + ssn + "’“

SSN参数来自于用户的输入：

  • 参数未经验证或编码
  • 黑客输入： 1234’ OR ‘1’=‘1

应用程序构造查询语句：

  • SELECT * FROM USERS WHERE SSN=‘1234’ OR ‘1’=‘1’ （永真逻辑）
  • 结果返回数据库中的每一个用户
🕤 2.1.2 SQL注入攻击流程

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/47e4b1c194ad4747a0c4c63ba124ec5f.png)
![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/c9c8e3eb827e48e29cc5c616becee2a0.png)

  1. Web程序提供了用户输入的表单；
  2. 攻击者通过填写表单数据发起攻击；
  3. Web程序通过SQL语句的形式将攻击递交给数据库；
  4. 数据库执行SQL语句，将执行结果加密后返回给应用程序；
  5. 应用程序解密数据，将结果发送给用户（攻击者）。

说明：SSL、防火墙等安全措施对于此类攻击完全没用。

实战：🔎 IBM所提供的Web安全漏洞演示网站

  1. Web应用有一个登录页面，这个登录页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码，登录页面中输入的内容将直接用来构造动态的SQL命令 或者直接用作存储过程的参数
System.Text.StringBuilder.query = new System.Text.String.Builder（“SELECT * from Users WHERE login =“).Append（txtLogin Text).Append（“'AND password=“').Append（txtPassword.Text).Append（“”）
  1. 攻击者在用户名字和密码输入框中输入 'or'1'='1 的内容
  2. 服务器运行上面的ASP NET代码构造出查询用户的SQL命令，最后得到的SQL命令变成
SELECT * from Users WHERE login = ‘or '1'='1'  AND  password ‘or '1'='1'

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/b2be84f271654a26a17e665039ab2535.png)

🕤 2.1.3 SQL注入检测

🔎
DVWA靶场——下载与安装

🔎 sqlmap详细使用教程

防御注入漏洞 ：

  • 使用 特定语言的库函数 来代替shell命令和系统调用；
  • 对用户输入的信息进行 严格检查和过滤 ：
    • 数据类型（字符串、整数等）正确吗？
    • 使用的是允许的字符集吗？
    • 输入满足格式要求吗？
    • ……
  • 使用“ 最小权限 ”限制数据库用户的权限

🔎
如何判断是字符型注入还是数字型注入

🕤 2.1.4 实验：SQL注入

使用合天网安实验室进入WEB渗透测试实验平台，并进入SQL注入进阶实验

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/5453e098df684325bd2ac8aa21e3a887.png)
实例1、热身运动，不设防
关键代码：

$sql = "SELECT * FROM users where name='";
$sql .= $_GET ["name"]."'";
$result = mysql_query ($sgl);

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/4dbc3c78626a4b8e85fa7f66c18df502.png)
![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/94b6299367ef4df489a5b8c693dddac8.png)
实例1是字符串型注入

判断该网络后台数据库users表格的列数：为5列
![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/889abe08a3b443438860737ddcdcd2c7.png)

判断该网络后台数据库users表格的每一列的数据类型
![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/93c02ac76f3640628c9eca72abc459db.png)

获取该网络后台数据库的数据库名
![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/8952b064c5aa4ec99bd9da09b143424c.png)
实例2、节约是种美德，少用空格
关键代码：

if (preg_match ( '/ /', $_GET ["name"])){
	die("ERROR NO SPACE");
}
$sql = "SELECT * FROM users where name='";
$sql .= $_GET ["name"]."'";
$result = mysql_query ($sql);

上述步骤与实例1基本相同，提示：URL中%20表示空格，可替代成%a0，%a0在Mysql中为换行符。注释指令可用#并用%23编码进行替代。

🕘 2.2 跨站脚本（XSS）攻击及防范

定义：跨站脚本(XSS)漏洞发生在应用使用用户提供的数据并发送给web浏览器而未经第一次验证或编码的时候。XSS允许攻击者在受害者的浏览器中执行脚本，这可以劫持用户会话、篡改网站、可能引入蠕虫等。

🕤 2.2.1 工作原理

原理：输入插入包含有JavaScript或其它恶意脚本的HTML标签代码。

<script>alert(XSS)</script>

问题根源：不当的服务器端输入检查，从而允许用户输入可被客户端浏览器解释的脚本命令。

XSS是 最普遍 的Web程序安全问题。

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/aa102926448f45abb5fab1a56de979dc.png)

DOM，文件对象模型，Document Object
Model.是给HTML和xml文件使用的一组API，是建立网页与Script语言沟通的桥梁，比如table对象代表HTML中的表格，可以由JavaScript脚本取用

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/72850cc48f9f4f54bbb9fdf134b15fb0.png)
![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/0654d749bd944331957d4c6fda24d9d5.png)

🕤 2.2.2 反射式XSS
  • 也称为 非持久性 跨站脚本攻击，是一种 最常见 的跨站脚本攻击类型。
  • 与本地脚本漏洞不同的是Web客户端使用Server端脚本生成页面为用户提供数据时，如果 未经验证的用户数据 被包含在页面中而未经HTML实体编码，客户端代码便能够 注入到动态页面 中。
  • 在这种攻击模式下，Web程序不会存储恶意脚本，它会将 未经验证的数据通过请求发送 给客户端，攻击者就可以构造恶意的URL链接或表单并诱骗用户访问，最终达到利用受害者身份执行恶意代码的目的。

例子：
(1) Alice经常浏览Bob建立的网站。Bob的站点运行Alice使用用户名/密码进行登录，并存储敏感信息(比如银行帐户信息)；
(2) Charly发现Bob的站点包含反射性的XSS漏洞；
(3) Charly编写一个利用漏洞的URL，并将其冒充为来自Bob的邮件发送给Alice；
(4) Alice在登录到Bob的站点后，浏览Charly提供的URL；
(5)
嵌入到URL中的恶意脚本在Alice的浏览器中执行，就像它直接来自Bob的服务器一样。此脚本盗窃敏感信息(授权、信用卡、帐号信息等)，然后在Alice完全不知情的情况下将这些信息发送到Charly的Web站点。

🕤 2.2.3 储存式XSS

储存式跨站脚本攻击，也称为持久性跨站脚本攻击。如果Web程序 允许存储用户数据 ，并且存储的输入数据 没有经过正确的过滤
，就有可能发生这类攻击。

在这种攻击模式下，攻击者 并不需要利用一个恶意链接 ，只要用户访问了储存式跨站脚本网页，那么恶意数据就将显示为网站的一部分并以受害者身份执行。

🕤 2.2.4 DOM式XSS

DOM式XSS 攻击并不是按照“数据是否保存在服务端”划分的，它是 反射式XSS
的一种特例，只是由于DOM式XSS的形成原因比较特殊，因此把它单独作为一个分类。

DOM式XSS 攻击是通过修改页面DOM节点数据信息而形成的。看下面的代码。

<script
  function test(){
   var str = document.getElementById("input").value;
   document.getElementById("output").innerHTML="<a href="+str+"">test</a>";
   }
</script>
<div id="output"></div>
<input type="text" id="input" size=50 value=""/>
<input type="button" value="提交" onclick="test()"/>

如果构造数据“‘ onclick=’javascript:alert(/xss/)”，那么最后添加的html代码就变成了“<a href=’ ‘ onclick=’javascript:alert(/xss/)’>test</a>”，插入一个onclick事件，点击提交按键，那么就会发生一次DOM式xss攻击。

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/cf66cee83b2b47658c6c7b557cac81d9.png)

🕤 2.2.5 防御XSS

对Web应用程序的所有输入进行 过滤 ，对危险的HTML字符进行 编码 ：

  • ‘<’ , ‘>’ → ‘&lt;’ , ‘&gt;’
  • ‘(‘ , ‘)’ → ‘&#40;’ , ‘&#41;’
  • ‘#‘ , ‘&’ → ‘&#35;’ , ‘&#38;‘

对用户，谨防不明链接；
防止访问已知的恶意网站；
执行手工或自动化代码扫描，确定并消除潜在的XSS漏洞。

🕤 2.2.6 实验：XSS攻击

尝试构造语句使浏览器执行弹出对话框的脚本。

实例一、热身运动，不设防

关键代码：

<?php
	echo $_GET["name"];
?>

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/f9b3d4b603864ba4a384ffbc13c9d064.png)

实例二、小写不行，就大写吧

关键代码：

	$name = $_GET["name"];
	$name = preg_replace("/<script>/", ""，$name);
	$name = preg_replace("/<\/script>/",""，$name);
echo $name;

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/749d0de62a814638acb39c89868fc15d.png)

实例三、大写小写都不行，看你怎么办？

关键代码：

	$name = $_GET[ "name"];
	$name = preg_replace( " /<script>/i",""，$name);
	$name = preg_replace( " /<\/script>/i",""，$name);
echo $name;

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/a93adc95583f474ab8be9bdac2cb5b56.png)

实例四、换一个角度，阳光依旧

关键代码：

if (preg_match('/script/i'，$_GET["name"])) {
	die("error");
}

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/927f9d6babb44c74a39dff3cd3cb8ed1.png)

实例五、限制了我的左手，我还有右手

关键代码：

if (preg_match('/alert/i'，$_GET["name"])) {
	die("error");
}

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/306d4a1cf5174ca8b423c98dcf5cb753.png)

实例六、大胆去思考，小心去求证

关键代码：

<script>
	var $a= "<?php echo $_GET["name"]; ?>";
</script>

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/e67d878b1f74472ca6bbe34cae6c24ef.png)

🕘 2.3 Cookie欺骗及防范

🕤 2.3.1 伪造Cookie信息

伪造Cookie信息，绕过网站的验证过程，不需要输入密码，就可以登录网站，甚至进入网站管理后台

网站登录验证代码：

<%
if request.Cookies("lunjilyb")("username")=""then response.redirect "login.asp"	/* 如果用户名为空，就
跳转到登录界面*/
endif
if request.Cookies("lunjilyb")("password")=""then response.redirect "login.asp"   /* 如果口令为空，就跳转到登录界面*/
endif
if request.Cookies("lunjilyb")("randomid")<>12 then response.redirect "login.asp"   /* 如果randomid值不等于12，就跳转到登录界面*/
endif
%>

利用request.Cookies语句分别获取Cookies中的用户名、口令和randomid的值。如果用户名或口令为空或randomid值不等于12就跳转到登录界面。也就是说，程序是通过验证用户的Cookie信息来确认用户是否已登录。然而，Cookie信息是可以在本地修改的，只要改后的Cookie信息符合验证条件（用户名和口令不空且randomid值等于12），就可进入管理后台界面。

判断是否有删帖权限的代码：

if Request.Cookies("power")="" then
  response.write"<SCRIPT 1anguage=JavaScript>alert(‘你还未登录论坛! ');</SCRIPT>"
  response.end
else
 if Request.Cookies("power')<500 then
   response.write"<SCRIPT 1anguage=JavaScript>alert('你的管理级别不够! );</SCRIPT>"
   response.redirect"http://cnc.cookun.com"
   response.end
 endif
endif

只要Cookie中的power值不小于500，任意用户都可以删除任意帖子。同样可以利用上面介绍的方法进行Cookie欺骗攻击面

上面介绍的两个攻击例子之所以成功，是因为 在Cookie中保存了用户名、口令以及权限信息而留下了安全隐患 。

  • 安全原则 ：一般情况下，网站会话管理机制仅将会话ID保存至Cookie，而将数据本身保存在Web服务器的内存或文件、数据库中
🕤 2.3.2 监听Cookie来实现会话劫持

如果Cookie中没有设置安全属性secure”，则Cookie内容在网络中用明文传输，攻击者监听到Cookie内容后可以轻松实现会话劫持

Q：为什么会不设置安全属性？
A：不设置Cookie安全属性的原因主要有两种：一种是Web应用开发者不知道安全属性或不愿意使用安全属性；第二种是设置安全属性后应用无法运行。

🕘 2.4 CSRF攻击及防范

定义：CSRF（跨站请求伪造）攻击迫使已登录的受害者浏览器向易受攻击的Web应用程序发送预先验证的请求，然后强制受害者浏览器执行对攻击者有利的恶意操作。

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/4b20b9080ff44c0dada7151aa10e0a5f.png)
现有银行的网银交易流程要比例子复杂得多，同时还需要USB key、验证码、登录密码和支付密码等一系列安全信息，一般并不存在CSRF安全漏洞，安全是有保障的。

重大的差别：

  • CSRF利用的是Web服务器端的漏洞
  • XSS利用的是Web客户端的漏洞

XSS攻击是实施CSRF攻击前的一个重要步骤：

  • 攻击者通过XSS攻击获取有用的攻击信息，比如通过XSS伪造一个提示用户输入身份信息的表单。

防御CSRF攻击：

  • 设定短暂的可信用户会话时间，完成任务后记得退出可信会话，删除所有cookie；
  • 每次提出一个可信行为时，对发出请求的用户进行验证；
  • 让网站记住登录用户名和密码时要小心。留在客户端的登录信息可能会攻击者加以利用；
  • 在URL和表单中增加的每个请求，必须提供基本会话令牌以外的每个请求用户验证；
  • 从Web应用程序中删除所有XSS漏洞。

| 嵌入机密信息（令牌）| 再次认证（输入密码）| 检查Referer
—|—|—|—
工作原理|
在访问需防范CSRF的页面（登录、订单确认、密码修改确认页面等）时需要提供第三方无法知晓的机密信息（令牌，token）。假设请求通过POST方式提交，则可以在相应表单中增加一个隐藏域：<input type="hidden" name="_token" value="tokenvalue"/>
token值由服务端生成，表单提交后token的值通过POST请求与参数一同带到服务端，并在服务端进行token校验，如果请求中没有token或者token内容不正确，则认为是CSRF攻击而拒绝该请求。每次会话可以使用相同的token，会话过期，则token失效，攻击者因无法获取到token，也就无法伪造请求|
执行操作前让用户再次进行认证（如输入密码），以确认请求是否由用户自愿发起的| 在通常情况下，访问一个安全受限页面的请求都来自于同一个网站。Referer
记录了HTTP请求的来源地址，检查Referer值是否是执行页面的上一个页面（输入页面或确认页面等），如果不是则很可能是CSRF攻击

🕘 2.5 目录遍历及其防范

许多Web应用支持外界以参数的形式来指定服务器上的文件名，如果服务器在处理用户请求时不对文件名进行充分校验，就可能出问题，如：

  • 文件被非法获取 ，导致重要信息被泄露；
  • 文件被篡改 ，如篡改网页内容以发布不实消息，设置圈套将用户诱导至恶意网站，篡改脚本文件从而在服务器上执行任意脚本等；
  • 文件被删除 ，如删除脚本文件或配置文件导致服务器宕机等

一般来说，如果Web应用满足以下3个条件时，就有可能产生目录遍历漏洞

  • 外界能够指定文件名

  • 能够使用绝对路径或相对路径等形式来指定其它目录的文件名

  • 没有对拼接后的文件名进行校验就允许访问该文件

    <?php define('TMPLDIR',‘/var/www/example/tmp1'); $tmp1 -$_GET( 'template'); ?> <?php readfile(TMPLDIR, $tmp1,".html'); ?>

http://example.cn/example/ex.php?template=../../../../etc/hosts%00
将显示/etc/hosts文件内容

防御：

  • 避免由外界指定文件名
    • 将文件名固定，保存在会话变量中，不直接指定文件名，而是使用编号等方法间接指定
  • 文件名中不允许包含目录名
    • 不同系统中表示目录的字符有所不同，常见的有：/、\、:等
  • 限定文件中仅包含字母或数字
    • 有些攻击使用不同的编码转换进行过滤性的绕过，如通过对参数进行URL编码来绕过检查
      downfile.jsp?filename= %66%61%6E%2E%70%64%66

🕘 2.6 操作系统命令注入及防范

很多Web应用编程语言支持应用通过Shell执行操作系统（OS）命令。通过Shell执行OS命令，或开发中用到的某个方法在其内部使用了Shell，就有可能出现恶意利用Shell提供的功能来任意执行OS命令的情况，这就是OS命令注入。

// 页面功能是发送电子邮件( sendmai1.htm1)
<body>
<form action ="send.php" method="POST">
请输入您的邮箱地址<br>
邮箱地址<input type ="text" name ="mail"<br>
邮件内容<textarea name ="con" cols = "20" rows = "3"></textarea><br>
<input type = "submit" value ="发送”>
</form>
</body> // sendmail.html结束



// 接收页面的处理脚本(send.php)
<?php
	$mail = $_POST['mail'];
	// 调用OS命令sendmail将邮件发送到表单中填入的邮件地址$mail
	// 邮件信息保存在template.txt中
	system("/usr/sbin/sendmail -I <template.txt $mail");
	// 省略代码
<body>
	邮件已发送
<body> //send.php结束

如果用户在邮箱地址处输入的是正常的邮箱地址，该页面将给该邮箱发送一封正常的电子邮件。但是，如果攻击者在邮箱地址处输入的是以下内容:
list@example.com; cat /etc/passwd
则在页面上点击“发送”按钮后，页面上将显示的是系统口令文件/etc/passwd
的内容。此处攻击者只是用cat命令显示文件内容，他也完全可以用Web应用的用户权限执行任何操作系统命令，如删除文件、下载文件、执行下载来的恶意软件等。

上述攻击成功的主要原因是Shell支持连续执行多条命令，如Unix操作系统Shell中使用分号；或管道|等字符支持连续执行多条命令，Windows操作系统cmd.exe使用&符号来连接多条命令。这些符号一般称为Shell的元字符，如果OS命令参数中混入了元字符，就会使攻击者添加的操作系统命令被执行，这就是OS注入漏洞产生的原因

OS命令注入攻击的一般流程为：

  1. 从外部下载攻击用软件；
  2. 对下载来的软件授予执行权限；
  3. 从内部攻击操作系统漏洞以取得管理员权限；
  4. 攻击者在Web服务器上执行攻击操作，如：浏览、篡改或删除Web服务器内的文件，对外发送邮件，以此服务器作跳板攻击其他服务器等。

OS命令注入攻击防御策略：

  • 选择不调用操作系统命令的实现方法，即不调用Shell功能，而用其它方法实现；
  • 避免使用内部可能会调用Shell的函数；
  • 不将外部输入的字符串作为命令行参数；
  • 使用安全的函数对传递给操作系统的参数进行转义，消除Shell元字符带来的威胁。由于Shell转义规则的复杂性以及其它一些环境相关的原因，这一方法有时很难完全凑效。

🕘 2.7 HTTP消息头注入攻击及防范

指在重定向或生成Cookie时，基于外部传入的参数生成HTTP响应头：

  • HTTP响应头信息一般以文本格式逐行定义消息头，即消息头之间互相以换行符隔开。攻击者可以利用这一特点，在指定重定向目标URL或Cookie值的参数中插入换行符且该换行符又被直接作为响应输出，从而在受害者的浏览器上任意添加响应消息头或伪造响应消息体：生成任意Cookie，重定向到任意URL，更改页面显示内容，执行任意JavaScript而造成与XSS同样效果

看下面的例子
http://example.com/web/in.cfg?url=http://example.com/%0D%0ALocation: + http://trap. com /web/attack.php
执行之后，浏览器会跳转到恶意网站trap.com/web/attack.php，而不是期望的正常网站http://example.com。造成这一结果的主要原因是，CGI脚本里使用的查询字符串url中包含了换行符（%0D%0A）。出两个消息头：
Location: http://example.com
Location: http://trap.com/web/attack.php

采用类似方法可以生成任意Cookie，看下面例子
http://example.com/web/in.cfg?url=http://example.com/web/exampple.php%0D%0ASet- Cookie: + SESSID=ac13rkd90
执行之后，两个消息头：
Set-Cookie: SESSID=ac13rkd90
Location: http://example.com/web/exampple.php

防御：

  • 不将外部传入参数作为HTTP响应消息头输出，如不直接使用URL指定重定向目标，而是将其固定或通过编号等方式来指定，或使用Web应用开发工具中提供的会话变量来转交URL；
  • 由专门的API来进行重定向或生成Cookie，并严格检验生成消息头的参数中的换行符

🕘 2.8 其他攻击

🕤 2.8.1 恶意文件执行

定义：易受远程文件包含（RFI）攻击的代码允许攻击者包含恶意代码和数据，从而导致毁灭性的攻击，如服务器完全被攻陷。恶意文件执行攻击会影响 PHP、XML
和任何接受用户文件名或文件的框架。

  • 恶意文件执行漏洞也称为 不安全的远程文件包含漏洞 ；
  • 需要用户提供输入文件名的Web程序容易受到攻击：如果对用户输入不验证，攻击者可借此操控Web程序执行系统程序或外部URL；
  • 允许上传文件给Web程序带来的危害更大
    • 可以将可执行代码放置到Web应用中去；
    • 可以替换Session文件、日志文件或认证令牌

防御：

  • 禁止用户输入被用作输入文件片断；
  • 对于必须要用户输入文件名、URL的地方，执行严格的检查验证输入合法性；
  • 文件上传的处理要非常小心：
    • 文件只允许上传到webroot目录以外的目录中，这样能防止文件被执行；
    • 限制或隔离Web程序对文件的访问权限。
🕤 2.8.2 不安全的直接对象引用

定义：当开发人员将内部实现对象的引用（例如文件、目录、数据库记录或键）暴露为URL或表单参数时，就会发生直接对象引用。攻击者可以操作这些引用，未经授权访问其他对象。

  • 不安全的直接对象引用漏洞也常称为 目录遍历漏洞 ；
  • Web程序常常会暴露内部对象，包括：
    • 文件或目录
    • URL
    • 数据库口令
    • 数据库的一些对象名称，比如表名
  • 如果 访问控制 配置不合理，攻击者就可以不经授权地操作这些暴露的内部对象。

防御：

  • 锁定Web目录 。使得通过网络访问Web服务器的用户都不能访问除专门用于存放Web内容的目录以外的目录；
  • 对于每一次对象引用都要 重新验证授权 ；
  • 禁止通过参数暴露 内部对象；
  • 建议使用间接映射的方法取代简单的直接对象引用，比如：
    http://www.example.com/application?file=1
🕤 2.8.3 信息泄露和不当的错误处理

定义：应用程序可能会无意间泄露关于其配置、内部工作原理或违反隐私的信息，这可能是由于应用程序存在各种问题。攻击者利用这些弱点来窃取敏感数据或进行更严重的攻击。

敏感信息泄露常常细微难以察觉

常见的脆弱点：

  • 查明堆栈跟踪 ：为程序员提供详尽的信息，说明错误发生前调用了哪些程序或函数。相同的信息还可为计算机罪犯提供函数、对象名称，以及其它设计针对报告错误的系统的攻击的相关情况。
  • SQL状态信息 ：揭示数据库、字段和表名称——在计划实施SQL注入之类的攻击时，与数据库有关的信息十分重要
  • 登录信息 ：登录失败后，通知用户是否用户ID或密码出错——登录失败可能是由于ID或密码错误造成的。这为一个对关键资产发动暴力攻击的攻击者提供重要信息。
  • 授权信息 ：确认某个文件——如果未获得授权的用户企图访问某个文件，返回的错误消息会告诉她没有取得访问那个资源的授权。如果她是一名试图定位某个包含敏感信息的文件的攻击者，错误消息就为她提供了肯定信息。

示例1：

Microsoft OLE DB Provider for ODBC Drivers error '80004005' 
[Microsoft][ODBC Microsoft Access 97 Driver] Can't open database ‘VDPROD'.

示例2：

java.sql.SQLException: ORA-00600: internal error code,
arguments: [ttcgnd-1], [0], [], [], [],
at oracle.jdbc.dbaccess.DBError.throwSqlException (DBError.java:169) 
at oracle.jdbc.ttc7.TTIoer.processError (TTIoer.java:208)

错误处理信息对于Debug非常有用，但是为攻击者提供了太多潜在可用的攻击信息！

防御：

  • 每个应用程序都应包含一个标准的错误处理框架来处理异常：禁止显示堆栈跟踪、数据库访问、协议等相关的信息；
  • Web程序应只提供尽量简短、“刚好够用”的错误处理信息给用户；
🕤 2.8.4 认证和会话管理不完善

定义：账户凭据和会话令牌通常没有得到适当的保护。攻击者通过窃取密码、密钥或身份验证令牌来冒充其他用户的身份。

会话（Session）管理

  • HTTP/HTTPS是“无状态”协议。意味着每一次用户请求都需要认证
  • 会话管理解决了这样的问题：当一个用户得到服务器认证后，服务器如何识别和处理这个认证用户接下来的请求
  • Web程序一般会提供内置的会话跟踪方法，方便用户的使用；
  • Web开发者常采用自己的策略来实现会话状态管理，可能会犯错误而导致安全问题。

会话管理：Session ID

  • 唯一地标识用户
  • 一个ID仅用于一次认证会话
  • 由服务器生成
  • 以如下的形式发送给客户端：
    • 隐式变量
    • HTTP cookie
    • URL查询串
  • 服务器期待用户在下一次请求时发送同样的ID（用来标识用户已被认证）

会话管理：Session Hijacking

  • Session ID可能被泄露和猜解，黑客可以：
    • 获取用户的帐号
    • 做任何受害者能做的事情：一个使用同样Session ID的攻击者将拥有和真正用户相同的特权。

认证和会话管理攻击流程：
![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/a07c106b7cf641409f6002121fc835aa.png)

防御：

  • 使用长且复杂的随机Session ID，难以猜解；
  • 对Session ID的传输、存储进行保护，防止被泄露和劫持；
  • 使用SSL时，必须保护认证和Session ID两部分的内容；
  • URL查询字符串中不要包含有User/Session任何信息。
🕤 2.8.5 不安全的加密存储

定义：Web程序很少正确使用加密功能来保护数据和凭据。攻击者利用弱保护的数据进行身份盗窃和其他犯罪活动，例如信用卡欺诈。

常见的问题：

  • 对敏感信息没有加密；
  • 继续使用已被证明加密强度不高的算法（ MD5, SHA-1, RC3, RC4, etc.）；
  • 加密方法使用不安全，比如对加密口令的存储不加保护；
  • 尝试使用自己发明的加密方法（实践证明这种方法比较糟糕！）。

示例：
![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/ca561c67156c415f96afc95edf0af948.png)

防御：

  • 如非必要，不要保存敏感信息；
  • 确保所有的敏感信息都被加密，检查敏感信息的归档过程和政策；
  • 只使用经过证明的标准加密算法；
  • 小心存储口令、证书等信息。
🕤 2.8.6 URL访问缺少限制

定义：通常，应用程序仅通过防止向未经授权的用户显示链接或URL来保护敏感功能。攻击者可以利用此弱点直接访问这些URL并执行未经授权的操作。

当Web应用缺少对某些URL的访问限制，攻击者可以直接在浏览器中输入URL来访问。

比如：

  • Add_account_form.php 在显示这个表单页时要先对用户的管理员角色进行验证；
  • 表单填好后发送给add_acct.php执行添加帐号的功能；
  • 如果不限制add_acct.php的直接访问，攻击者直接在浏览器中访问该页面，就绕过了权限检查。

防御：

  • 从早期做起！
    • 从需求阶段就要制定详细的安全策略；
    • 从页面到每一个功能，都只由相应的经过认证的角色来访问；
    • 访问控制策略越简单越好。
  • 彻底地测试！
    • 进行详尽地测试保证访问控制没有被旁路；
    • 尝试所有的非法访问；
    • 测试时不要跟随Web应用的正常工作流；

🕒 3. HTTPS

🕘 3.1 提出背景：不安全的通信

定义：当需要保护敏感通信时，应用程序经常无法加密网络流量。

存在的问题：

  • 攻击者可以从网络上任何一个被攻陷的系统或设备上嗅探网络流量：Web流量往往是不加密的
  • 使用SSL也可能遭受“中间人”攻击

🕘 3.2 防御

保证所有用来认证和传输敏感信息的连接都使用基于SSL/TLS的HTTPS

超文本传输安全协议（Hypertext Transfer Protocol
Secure，HTTPS），是一种将HTTP和SSL（或TLS）结合来实现Web浏览器和服务器之间的安全通信协议，也称为HTTP over
TLS，HTTP over SSL或HTTP Secure。基于SSL或TLS的HTTP并没有本质区别，都被称为HTTPS

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/3ccc9c364844476aac24d16bf47eeae5.png)

[🔎 【PPT分享】清华大学郑晓峰： 端到端安全协议的威胁、演进和部署](https://www.inforsec.org/wp/wp-
content/uploads/2019/01/Session3-%E9%83%91%E6%99%93%E5%B3%B0%E6%9B%B4%E6%96%B0PPT%E7%AB%AF%E5%88%B0%E7%AB%AF%E5%AE%89%E5%85%A8%E5%8D%8F%E8%AE%AE%E7%9A%84%E5%A8%81%E8%83%81%E3%80%81%E6%BC%94%E8%BF%9B%E5%92%8C%E9%83%A8%E7%BD%B2_inforsec.pdf)

从用户使用的角度看，HTTP和HTTPS的主要区别是URL地址开始于http://还是https://

  • 一个标准的HTTP服务使用80端口，而一个标准的HTTPS服务则使用 443 端口

当使用HTTPS时，下述通信内容被加密：请求的 文件的URL，文件的内容 ，浏览器 表单的内容
（由浏览器使用者填写），从浏览器发送到服务器或从服务器发送给浏览器的 Cookie ， HTTP标题 的内容

连接建立 ：
作为HTTP用户的代理程序（也是TLS的用户）首先向服务器的指定端口（443）发起TCP连接请求。成功建立TCP连接后，向服务器发送TLS
ClientHello，开始TLS握手过程。当TLS握手过程完成后，用户将发起第一次HTTP请求。此时，所有HTTP协议数据都要以TLS应用数据的形式通过TLS记录协议加密传输。在此过程中，要遵守HTTP协议规范，包括保留连接。

Q：HTTP连接的含义？
A：HTTPS连接具体多个层面的意思。在HTTP层面，一个HTTP用户通过向下一层（TCP或SSL/TLS）发送一个连接请求来向服务器请求建立一条连接；在TLS层面，一个会话建立在一个TLS用户和一个TLS服务器之间，可以在任何时间支持一条或多条TLS连接。一条TLS连接请求的开始总是伴随着一条TCP连接的建立。

连接关闭 ：
关闭一条HTTPS连接要求关闭TLS与其对应的对端实体之间的连接，这意味着也要关闭TLS的下层TCP连接。在TLS层面，关闭连接的最好方式是两端都用TLS告警协议发出一个“close_notify”告警。在发出“close_notify”后，一个TLS实体会立即关闭该连接，而不会等待它的对等实体发来“close_notify”告警，从而可能造成“不完整的关闭”。

服务器端的HTTPS 部署情况 ：
![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/2526dbabebb8455caa09d06f41a09bad.png)

HSTS (HTTP Strict Transport Security)

  • IETF提出的一种新的Web安全协议，其目的是 强制客户端（如Web浏览器）使用HTTPS与服务器进行通信 。使用HSTS协议的网站将保证浏览器始终使用HTTPS连接到服务器，不需要用户在浏览器的地址栏中手工输入HTTPS。当客户端通过HTTPS向服务器发出请求时，服务器在返回的超文本传输协议响应头中包含Strict-Transport-Security字段。
  • HSTS可以用来 抵御SSL剥离攻击 （一种用来阻止浏览器与服务器之间创建HTTPS连接的中间人攻击方法，由Moxie Marlinspike在2009年的黑帽大会上提出），因为只要浏览器曾经与服务器创建过一次安全连接，之后浏览器会强制使用HTTPS，即使URL链接中的https被替换成了http

判断一个域名是否支持HTTPS：🔎 Internet.nl

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/0c2ab8d7eea941d78ced2229a27afe23.png)![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/92104a03ee57477b9b0a8008a2d22ada.png)

有了HTTPS，即使被中间人攻击，也能防止攻击

  • 2020.3.26 国内部分地区网络出现中间人攻击（通过骨干网络进行劫持 HTTPS的443端口）：GitHub、京东等被劫持。因证书不对，被浏览器阻止访问

🔎 国内部分地区网络出现中间人攻击：GitHub、京东等被劫持

🔎 域名注册商GoDaddy客服被钓鱼攻击，多家公司域名解析被篡改

🔎 HTTPS 劫持漫谈：代理劫持与透明劫持

简答题：小王某次出差住宿，利用酒店提供的Wi-
Fi来上网，当他开始访问一个自己经常访问的网站时，浏览器却弹出类似“你的连接不是专用连接”，将鼠标放在浏览器地址栏的证书风险处，下拉显示“证书无效之类的信息”，如下图所示。浏览器提示用户“继续访问”还是“返回”。而自己平时在办公室访问该网站却没有出现该提示。请分析可能的原因。

![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/ade474a1805842f796b08858e752a9cf.png)
![在这里插入图片描述](https://img-
blog.csdnimg.cn/direct/c9675ffbd5484646ad59fbd109df3396.png)

答：最可能的原因是酒店在监听用户的上网，酒店使用自签名证书或浏览器不信任的CA颁发的证书作为中间人分别与浏览器与目标网站进行加密通信，解密、加密用户浏览器与目标网站之间的通信。

OK，以上就是本期知识点“Web应用安全”的知识啦~~ ，感谢友友们的阅读。后续还会继续更新，欢迎持续关注哟📌~
💫如果有错误❌，欢迎批评指正呀👀~让我们一起相互进步🚀
🎉如果觉得收获满满，可以点点赞👍支持一下哟~

❗ 转载请注明出处
作者：HinsCoder
博客链接：🔎 作者博客主页

学习计划安排


我一共划分了六个阶段，但并不是说你得学完全部才能上手工作，对于一些初级岗位，学到第三四个阶段就足矣~

这里我整合并且整理成了一份【282G】的网络安全从零基础入门到进阶资料包，需要的小伙伴可以扫描下方CSDN官方合作二维码免费领取哦，无偿分享！！！

如果你对网络安全入门感兴趣，那么你需要的话可以

点击这里👉网络安全重磅福利：入门&进阶全套282G学习资源包免费分享！

①网络安全学习路线
②上百份渗透测试电子书
③安全攻防357页笔记
④50份安全攻防面试指南
⑤安全红队渗透工具包
⑥HW护网行动经验总结
⑦100个漏洞实战案例
⑧安全大厂内部视频资源
⑨历年CTF夺旗赛题解析

程序员--青青
关注
  • 18
    点赞
  • 踩
  • 24
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Web 安全学习笔记
hack0919的博客
04-05 193
对于从来没有接触过网络安全的同学，我帮你准备了详细的学习成长路线图
《白帽子讲web安全》学习笔记——web安全概述
a2562614613的博客
08-28 804
一、安全的三要素 1、机密性 机密性要求保护数据内容不被泄露，加密是实现机密性要求的常见方法，比如常见的对称加密算法和非堆成加密算法。 2、完整性 完整性要求保护数据内容是完整的，没有被篡改，常见的保证一致性的技术手段是数据签名。 3、可用性 可用性要求保护资源是“随需而得”。安全领域中，拒绝服务攻击破坏得就职安全的可用应。 安全领域中，除以上要素外，仍然存在一些其他要素，比如不可抵赖性、可审计性，但最重要的要素便是以上三个。在...
WEB应用脆弱性防止策略 常见的16种WEB攻击以及解决方案
主题模板站的博客
01-31 509
比如在用户登陆时，提示的这样的错误信息【用户密码不正确】，从侧面就说明了系统中存在一个叫做【userid】的用户。因为这种应用的灵活性很大，用户输入的自由度也很高，所以对于WEB应用的恶意攻击也比较容易。一定要进行错误处理，错误处理的消息要显示为用户可理解的内容，不要把中间件（WEB服务器）的错误消息显示出来。对于固定的SQL语句，一般在应用程序层不做处理，推荐添加一个包装类，把这些固定的SQL操作控制起来。而对于动态生成的SQL语句，就需要对用户的输入进行处理，一般的处理是把【'】转换成【“】。
【web安全】10大Web应用安全威胁及防护建议_可以从哪些方面保证web安全
最新发布
weixin_57514792的博客
08-09 675
10大Web应用安全威胁及防护建议
安全：Web 安全学习笔记
weixin_33893473的博客
12-05 245
背景 说来惭愧，6 年的 web 编程生涯，一直没有真正系统的学习 web 安全知识（认证和授权除外），这个月看了一本《Web 安全设计之道》，书中的内容多是从微软官方文档翻译而来，这本书的含金量不高，不过也不能说没有收获，本文简单记录一下我学习 Web 安全方面的笔记。 本文不涉及 IIS、Windows 和 SqlServer 的安全管理与配置，尽量只谈编程相关的安全问题。 最简单的 W...
Web安全学习笔记（一）
weixin_34303897的博客
09-19 96
Web安全学习笔记（一）： URL协议 HTTP协议 1. URL 2. HTTP协议 什么是HTTP HTTP的工作原理 HTTP报文 什么是Cookies HTTP请求方式 Referer请求的功能 HTTP状态码、Set-Cookies 转载于:https://www.cnblogs.com/ryomahan/p/7549870.html...
web安全学习笔记
(づ｡◕‿‿◕｡)づgigi奋斗在前端和刷题中╮(╯﹏╰)╭
08-17 2240
XSS 跨站脚本攻击，指攻击者在网页中嵌入恶意脚本，当用户浏览此网页时脚本就会执行，从而达到攻击者的目的，比如获取cookie、导航到恶意网站等。 分类 反射型XSS 将用户输入的存在XSS攻击的数据，发送给后台，后台并未对数据进行存储，也未经过任何过滤和转义，直接返回给客户端被浏览器渲染。就可能导致XSS攻击； 假设站点http://www.test.com/xss/refl
Web应用安全认知
weixin_40050195的博客
11-07 325
您还在为不清楚Web应用安全威胁而担心吗？常见的Web攻击是怎么发生的？影响会有多大？通过这门精心设计的在线课程+动手实验，您可以轻松Get到这些技能，并且真正体验到攻击者如何发起这些攻击。 目前云计算环境下的应用主要以Web应用为主，本认证课程旨在帮助学员了解Web应用的主要威胁，以及对常见的攻击，如：SQL注入攻击、XSS攻击、文件上传攻击等，有一定的理解。这样才能更好的在开发或运维过程中预...
Web安全学习笔记-Web-Sec Documentation
01-30
Web安全学习笔记——Web-Sec Documentation是一份详细的知识库，旨在帮助读者理解并掌握Web安全相关的理论和技术。文档首先从Web技术的演化、网络攻防技术的发展以及网络安全观的演变三个方面进行阐述，让读者对Web...
web学习笔记 —— 监听器
03-16
本学习笔记主要聚焦于理解监听器的概念、作用以及如何在实际应用中使用它们。 一、监听器概述 监听器是实现了特定接口的Java类，这些接口定义了对特定事件的处理方法。例如，`HttpSessionListener`用于监听会话的...
web学习笔记 —— 过滤器
05-25
本文将深入探讨过滤器的概念、工作原理以及如何在Java Web应用程序中使用过滤器。 过滤器是Servlet规范的一部分，它通过实现javax.servlet.Filter接口来创建。这个接口定义了三个主要方法：doFilter、init和destroy...
安全：Web安全学习笔记
02-26
说来惭愧，6年的web编程生涯，一直没有真正系统的学习web安全知识（认证和授权除外），这个月看了一本《Web安全设计之道》，书中的内容多是从微软官方文档翻译而来，这本书的含金量不高，不过也不能说没有收获，本文简单记录一下我学习Web安全方面的笔记。本文不涉及IIS、Windows和SqlServer的安全管理与配置，尽量只谈编程相关的安全问题。浏览器和服务器的通信采用无状态的HTTP协议。通过控制HTTP的请求头，可以控制：客户端缓存、Cookie、请求编码、相应编码等。请求内容向服务器提交数据（POST和GET），响应内容向浏览器发送数据。Cookie包含在每个请求和响应中，因此客户端和服
web学习笔记 —— DAO设计模式
03-16
通过阅读《318_DAO设计模式.pdf》这份文档，你可以深入理解DAO模式的原理、实现方式以及在Web开发中的应用。同时，文档可能还会介绍一些相关的工具和技术，如MyBatis的使用、Spring的AOP事务管理等，这些都是DAO模式...
web应用安全相关
willie_chen的专栏
12-22 2136
1、XSS（反射、持久型） 2、注入攻击（sql、OS） 3、CSRF 4、其他（Error code 、html注释、文件上传） 5、web应用防火墙
web安全学习笔记（1）
qq_34333059的博客
03-16 195
Web安全学习笔记（1） 部署虚拟机XP和2003 一、部署win xp 虚拟机 准备xp系统的iso镜像文件 准备xp系统的安装位置 a.安装win xp的虚拟机 b.优化虚拟机 调出桌面图标 安装VMware tools（安装驱动），重启操作（与真实机互动） 磁盘管理（创建D盘分区） ...
Web安全 学习笔记
农夫果园好好喝的博客
04-18 525
P1概念名词 1,1 域名 什么是域名？ 域名是有一串用点分隔的名字组成的Internet上某一台计算机或计算机组的名称，用于在数据传输时对计算机的定位标识（有时也指的是地理位置）。 什么是二级域名多级域名？ 二级域名：分两种 在国际顶级域名下的二级域名 国际顶级域名下二级域名，二级域名一般是指域名注册人选择使用的网上名称，如“yahoo.com”；上网的商业组织通常使用自己的商标、商号或其他商业标志作为自己的网上名称，如“microsoft.com”。 国家顶级域名下二级域名 在国家顶级域名之下二级域名
WEB安全学习笔记
chenrs727的博客
12-02 1975
基础入门 1.基础入门——基础概念 域名 什么是域名 域名（英语：Domain Name），又称网域，是由一串用点分隔的名字组成的Internet上某一台计算机或计算机组的名称，用于在数据传输时对计算机的定位标识（有时也指地理位置） 由于IP地址具有不方便记忆并且不能显示地址组织的名称和性质等缺点，人们设计出了域名，并通过网域名称系统（DNS，Domain Name System）来将域名和IP地址相互映射，使人更方便地访问互联网，而不用去记住能够被机器直接读取的IP地址数串。 比如www.bai
Web安全学习笔记
子曰小玖的博客
04-04 831
Contents: 1. 基础知识 1.1. Web发展简史 1.2. 计算机网络 1.3. 域名系统 1.4. HTTP标准 1.5. 代码审计 1.6. WAF 2. 信息收集 2.1. 域名信息收集 2.2. 站点信息收集 2.3. CDN Bypass 2.4. 端口信息 2.5. 其它 2.6. 参考链接 3. 内网渗透 3....
nginx 加密会话(ssl)cookie 中缺少 secure 属性
07-16
在nginx中，加密会话（ssl）cookie中缺少secure属性。secure属性是一个标记，用于确保cookie只能在通过HTTPS安全连接时传输。 缺少secure属性可能会导致安全风险。当缺少secure属性时，如果HTTP请求使用非加密的连接发送，那么cookie也会以明文形式传输，容易受到恶意攻击者的窃取或篡改。因此，为了保护敏感信息的安全性，应该始终向ssl会话cookie添加secure属性。 要在nginx中添加secure属性，可以通过以下方式进行配置： 1. 打开nginx配置文件。 2. 找到相关的server或location块，这里设置了ssl参数。 3. 在该块内找到包含proxy_cookie_path或proxy_cookie_domain的语句。 4. 在语句中添加"secure"属性，例如，proxy_cookie_path / "/; secure"。 5. 保存配置文件并重新加载nginx服务。 以上步骤将会使nginx服务器向客户端发送一个包含secure属性的加密会话cookie。这样，当使用非加密的HTTP协议发送请求时，浏览器将不会发送该cookie，保护了加密会话的安全性。 总之，通过为加密会话cookie添加secure属性，可以有效地提高安全性，并避免受到潜在的攻击威胁。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值