预计练习两年半的安全服务练习生的第二天

表单标签

        form表单是HTML语言中用于向服务器提交信息的标签

        常见属性

action	指定将表单数据发送到哪个URL
method	指定提交表单数据的方法，常用的有GET和POST，一般我们用POST，区别是：POST将数据作为HTTP发送，GET将数据作为URL查询字符串发送
enctype	encode type，当method属性为post时，该属性指定提交给服务器的MIME类型。默认值application/x-www-form-urlencode，multipart/form-data（上传的为文件）,text/plain
name	为表单定义一个名称，方便后期在脚本中引用，他也是我们向服务发送数据时键值对中的键
target	指定在何处打开表单提交的结果可能的值有_self（当前窗口），_blank（新建窗口），_parent（父窗口），_top（顶层窗口），<iframe>标签的name属性（即表单返回结果展示在<iframe>窗口）。
autocomplete	规定浏览器是否应该完成表单，用off/on来选择
novalidate	规定在提交表单时是否应该验证表单

PHP上传文件流程（代码思路）

        上传的一瞬间，会在临时文件夹生成一个临时文件，不过临时文件有一个move这样的函数，然后会将临时文件移动到目标路径，之后将会删除临时文件。文件包含要竞争怎么竞争呢？我们需要有两个线程，一个用来上传，一个用来包含，在临时文件还没有消失的时候，用另一个进程，将这个临时文件包含进来，生成一个新的文件。

1. 创建 HTML 表单，其中包含一个文件输入字段和一个提交按钮。
2. 在 PHP 代码中，使用诸如 is_uploaded_file() 和 move_uploaded_file() 的函数来验证并移动上传文件。
3. 在上传过程中，需要注意文件安全性。可以使用诸如 getimagesize() 或者 finfo_file() 的函数来验证上传文件的 MIME 类型和大小，以确保它是有效的图像或其他文件。
4. 在服务器上保存文件时，应该考虑使用安全的文件名和文件路径，以防止文件名猜测攻击或路径遍历攻击。
5. 在完成文件上传后，可以使用诸如 header() 的函数重定向到另一个页面，以便用户能看到已经上传的文件。

PHP条件竞争漏洞

        "PHP文件上传之条件竞争"指的是在使用PHP处理文件上传时可能出现的一种安全漏洞。这种漏洞是由于PHP本身的一个特性导致的，可能会让攻击者能够覆盖或者删除服务器上的文件。

        具体来说，PHP在处理文件上传时会在服务器上创建一个临时文件，然后将上传的文件内容写入该临时文件。在完成写入之后，PHP会将这个临时文件移动到最终的目标位置，并删除原来的临时文件。

        问题是，在这个过程中，有一个瞬间存在两个文件：临时文件和最终目标文件。如果在这个瞬间，另一个请求也在上传一个文件，那么这两个请求就会发生条件竞争。具体来说，就是两个请求都会创建临时文件，然后将内容写入这些临时文件，最后再将它们移动到最终的目标位置。由于这两个请求的执行是并行的，所以它们可能会交替执行。这样的话，就会导致最终的目标文件是其中一个请求上传的文件，而另一个请求上传的文件被覆盖掉了。

        为了避免这种情况的发生，可以使用PHP的 flock()函数对文件加锁，这样就可以保证在同一时刻只有一个请求能够访问这个文件。具体来说，可以在创建临时文件之后立即对其加锁，然后在完成写入操作之后再将其解锁。这样的话，就可以保证同一时刻只有一个请求能够访问临时文件，从而避免条件竞争的发生。

        但是要注意，使用 flock() 函数对文件加锁并不是完全安全的。有一种情况是，如果一个请求在写入临时文件时被阻塞，那么在这个请求被阻塞的期间，另一个请求可能会尝试访问这个文件。如果这样的话，就会发生条件竞争。为了避免这种情况的发生，还需要使用其他的技术来保证文件上传的安全。

        总之，条件竞争是一种常见的安全漏洞，在处理文件上传时要特别注意。使用 flock() 函数对文件加锁是一种常用的方法，但是并不是完全安全的，还需要使用其他的技术来保证文件上传的安全。

iframe标签

        <iframe> 标签用于在网页中嵌入另一个网页。可以使用 src 属性指定要在 iframe 中显示的网页的 URL，也可以使用 name 属性为 iframe 命名，以便在其他网页中链接到它。可以使用 width 和 height 属性来调整他的大小，也可以使用 CSS 样式来调整大小。

        还可以使用 frameborder 属性指定是否在 iframe 周围绘制边框，使用 scrolling 属性指定是否提供滚动条，或者使用 seamless 属性使 iframe 与父级网页中的内容看起来更流畅。

        示例代码：

        <iframe src="http://example.com" width="400" height="300" frameborder="0" scrolling="no">

        </iframe>

为什么我们不能嵌入百度的网页

        百度网页不能被 iframe 标签嵌入，是因为百度网站的服务器将网站的响应头中的 "X-Frame-Options" 设置为 "DENY"。这个响应头告诉浏览器不允许在 iframe 中展示百度网站的内容。

iframe中的sandbox

        iframe 标签的 sandbox 属性可以设置一组限制，以防止在 iframe 中运行的内容对当前页面造成安全威胁。sandbox 属性的取值可以是一个由空格分隔的参数列表，也可以是一个空值，表示启用所有限制。

        常见的参数有：

---

1. allow-same-origin：允许 iframe 内容与页面来自同一来源。
2. allow-top-navigation：允许 iframe 内容通过 JavaScript 访问当前页面的 window 对象，以及访问当前页面的 location 对象并导航到新页面。
3. allow-forms：允许 iframe 内容提交表单。
4. allow-scripts：允许 iframe 内容执行 JavaScript 代码。
5. allow-popups：允许 iframe 内容打开新的窗口。
6. allow-popups-to-escape-sandbox：允许 iframe 内容中的弹出窗口绕过 sandbox 限制。
7. allow-presentation：允许 iframe 内容使用 Presentation API。
8. allow-top-navigation-by-user-activation：允许 iframe 内容在用户点击链接或者按下按钮时导航到新页面。

---

注意：当 sandbox 属性设置为空值时，则会启用所有限制，即禁止 iframe 内容进行任何操作。

        举个例子，如果想让 iframe 内容能够提交表单，但是禁止执行 JavaScript 代码，那么可以这样使用 sandbox 属性：

        <iframe src="http://example.com" sandbox="allow-forms"></iframe>

        如果希望启动多个限制，可以将他们用空格分隔

        <iframe src="http://example.com" sandbox="allow-forms allow-top-navigation"></iframe>

X-Frame-Options

        X-Frame-OptionsHTTP 响应报头可以被用来指示一个浏览器是否应该被允许在一个以呈现页面<frame>，<iframe>或<object>。通过确保其内容未嵌入其他网站，网站可以使用此功能来避免 点击劫持 攻击。

X-Frame-Options有三种可能的指示：

X-Frame-Options:DENY

X-Frame-Options:SAMEORIGIN

X-Frame-Options:ALLOW-FROM https://example.com/

如果指定DENY，从其他站点加载时，不仅尝试在框架中加载页面失败，从同一站点加载时尝试这样做将失败。另一方面，如果指定SAMEORIGIN，只要包含在框架中的站点与为页面提供服务的站点相同，仍然可以在框架中使用该页面。

DENY无论站点尝试这样做，页面都不能显示在框架中。SAMEORIGIN该页面只能显示在与页面本身相同的源框架中。ALLOW-FROM_ uri_页面只能显示在指定原点的框架中。

        注意：设置元标记是没用的！例如，<meta http-equiv="X-Frame-Options" content="deny">没有效果。不要使用它！只有像下面的例子那样设置HTTP头X-Frame-Options才能工作。

配置 Apache

要配置 Apache X-Frame-Options为所有页面发送标题，请将其添加到您网站的配置中：Header always append X-Frame-Options SAMEORIGIN

要配置 Apache 来设置X-Frame-Options拒绝，请将其添加到您网站的配置中：

Header setX-Frame-Options DENY

要配置 Apache 以将其设置X-Frame-Options为ALLOW-FROM特定主机，请将其添加到您网站的配置中：

Header setX-Frame-Options "ALLOW-FROM Example Domain"

配置 nginx

要配置 nginx 发送X-Frame-Options头文件，请将其添加到您的 http，服务器或位置配置中：

add_header X-Frame-Options SAMEORIGIN;

配置 IIS

要配置 IIS 发送X-Frame-Options标题，请添加此站点的Web.config文件：<system.webServer>

…

        <httpProtocol>

                                <customHeaders>

                                        <add name="X-Frame-Options"value="SAMEORIGIN"/>

                                </customHeaders>

                        </httpProtocol>

                …

                </system.webServer>

referer

        Referer 是 HTTP 协议中的一个请求头字段，用于指示用户代理（通常是浏览器）在发送请求之前从哪个网页或资源跳转过来的。

        例如，如果我们在浏览器中访问网页 A，然后从网页 A 中的链接点击到网页 B，那么网页 B 的服务器将能够检测到您的浏览器在发送请求之前从网页 A 跳转过来。

        Referer 头的值可以是网页 A 的完整 URL，也可以是相对 URL。

        Referer 头通常用于追踪网站流量，分析网站来源和关键词，以及在特定情况下防止网站内容的盗链。

        注意：Referer 头的名称是 "referer"，但是在 HTTP 协议中拼写是 "referrer"，所以有时候可能会看到 "Referrer" 这个写法。

referer-policy

referer-policy 是 HTTP 头部字段，用于控制浏览器在发送请求时发送的 Referer 信息。Referer 是 HTTP 协议中的一个请求头字段，用来记录当前请求的来源地址。每当浏览器发出一个请求时，它会自动在请求头中加入 Referer 字段，标识请求的来源页面。

referer-policy 可以设置为以下几种值：

1. no-referrer：禁止发送 Referer 信息。
2. no-referrer-when-downgrade：当请求的协议与当前页面的协议不同时，禁止发送 Referer 信息。
3. origin：只发送当前页面的协议和域名，不发送路径信息。
4. origin-when-cross-origin：当请求的资源与当前页面不同源时，只发送当前页面的协议和域名，不发送路径信息。
5. same-origin：只有当请求的资源与当前页面来自同一来源时，才发送 Referer 信息。
6. strict-origin：只有当请求的协议与当前页面的协议相同时，才发送 Referer 信息，且只发送当前页面的协议和域名，不发送路径信息。
7. strict-origin-when-cross-origin：当请求的资源与当前页面不同源且请求的协议与当前页面的协
8. unsafe-url：发送完整的 Referer 信息，包括协议、域名和路径。
9. always：总是发送 Referer 信息，即使跨源请求。

        注意，referer-policy 并不是标准的 HTTP 头部字段，它是一个新的建议性字段，目前仍处于实验阶段。但是它已经被许多浏览器所支持，可以使用。

        使用方法很简单，在 HTML 文件的 head 标签内添加一个 meta 标签，并设置 name 属性为 referer-policy，然后设置 content 属性为所需的值即可。例如，如果想设置 referer-policy 为 strict-origin，可以这样写：

        <meta name="referer-policy" content="strict-origin">

referer-policy 的一些注意事项。

        首先，referer-policy 的设置是全局的，对整个页面都有效。如果你希望控制单个请求的 Referer 信息，可以使用 fetch API 的 Referrer-Policy 字段。

        其次，referer-policy 的取值会受到浏览器的限制。例如，如果你设置 referer-policy 为 always，但是浏览器不支持这个值，那么浏览器会忽略你的设置，使用默认的取值。

        最后，referer-policy 只能控制浏览器发送的 Referer 信息，并不能阻止服务器端获取 Referer 信息。如果你想保护用户的隐私，还需要使用其他方法，例如使用 HTTPS 加密传输数据。

        总的来说，referer-policy 是一个很有用的功能，能够帮助你控制浏览器发送的 Referer 信息。但是它仍处于实验阶段，受到浏览器的限制，所以使用时需要注意。

盗链

        "盗链"指的是某些网站或者应用程序通过直接调用其他网站的图片、视频等资源，而不是通过正常的超链接方式访问这些资源的行为。这种行为可能会对被盗链的网站造成很大的负担，因此需要采取措施来防止盗链的发生。

那么，应该怎么防止盗链呢？下面列举几种常用的方法：

1. 使用 HTTP 头部字段来防止盗链：在 HTTP 响应头部加入 "X-Frame-Options" 字段，可以防止网页被其他网站的 frame 或者 iframe 标签嵌入。
2. 使用 .htaccess 文件来防止盗链：可以在 .htaccess 文件中添加 RewriteRule 指令，来限制特定的网站或者 IP 地址访问你的网站的资源。
3. 使用 JavaScript 来防止盗链：可以在网页中使用 JavaScript 代码来检测当前网页是否被嵌入在其他网站的 frame 中，如果是的话就跳转到正常的超链接页面。
4. 使用图片的水印来防止盗链：可以在图片中加入一些显眼的水印，这样即使被盗链也能够看出来是哪个网站的图片。
5. 使用反盗链服务来防止盗链：可以使用一些专门的反盗链服务，比如 Cloudflare 等。这些服务会帮助你检测和防止盗链的发生，同时还可以提供一些额外的功能，比如内容加速、DDoS 攻击保护等。
6. 使用 CDN 服务来防止盗链：使用 CDN 服务，可以将你的静态资源分发到全球各地的边缘节点，这样可以大大减少对你的服务器的压力，同时也可以提高访问速度。很多 CDN 服务都提供了反盗链的功能，可以帮助你防止盗链的发生。
7. 使用图片链接来防止盗链：可以将图片的地址指向一个链接，这样就可以防止直接通过图片地址访问图片了。
8. 使用防盗链插件来防止盗链：如果你使用的是 WordPress 等内容管理系统，那么可以使用一些专门的防盗链插件，来帮助你检测和防止盗链的发生。

XSS和textarea无法生效

        XSS（Cross-Site Scripting，跨站脚本攻击）是一种常见的网络攻击方式，它通过注入恶意的脚本代码来攻击网站的安全。

        XSS 漏洞通常是由于网站对用户输入的数据没有进行正确的过滤和转义，导致恶意的脚本代码能够被注入到网站中并被执行。这样，攻击者就可以利用用户的浏览器执行恶意的脚本代码，达到攻击网站的目的。

        举个例子，如果一个网站的评论功能没有对用户输入的数据进行正确的过滤，那么攻击者就可以在评论中注入恶意的脚本代码，并将这些代码发布到网站上。当其他用户浏览这些评论时，就会触发恶意脚本的执行，导致各种后果。

        为了防止 XSS 攻击，应该对用户的输入数据进行严格的过滤和转义，以防止恶意的脚本代码被注入到网站中。此外，可以使用一些安全工具，比如 Web 应用防火墙、Content Security Policy 等，来帮助检测和防止 XSS 攻击的发生。

        通常来说，XSS 攻击可以通过向网页中注入恶意的 JavaScript 代码来实现。因此，可以通过含有 JavaScript 代码的 HTML 标签进行 XSS 攻击。

常见的 HTML 标签包括：

1. <script> 标签：可以用来在网页中嵌入 JavaScript 代码。
2. <img> 标签：可以通过设置图片的 src 属性来加载远程的 JavaScript 代码。
3. <iframe> 标签：可以通过设置 src 属性来加载远程的 HTML 页面，其中可能包含恶意的 JavaScript 代码。
4. <link> 标签：可以用来加载远程的 CSS 文件，其中可能包含恶意的 JavaScript 代码。

        此外，还有一些其他的标签，比如 <form>、<input>、<textarea> 等，也可能被用来进行 XSS 攻击。

        总之，XSS 攻击可以通过向网页中注入恶意的 JavaScript 代码来实现，可以使用各种 HTML 标签来注入这些代码。因此，网站开发人员应该对用户的输入数据进行严格的过滤和转义，以防止 XSS 攻击的发生。

textarea无法生效

        通常来说，XSS 攻击是通过向网页中注入恶意的 JavaScript 代码来实现的。如果攻击者想要使用 <textarea> 标签进行 XSS 攻击，那么就必须在 <textarea> 标签的内容中注入 JavaScript 代码。

        然而，<textarea> 标签的内容是可以用来填写文本的，而不是执行代码的。因此，在 <textarea> 标签的内容中注入 JavaScript 代码是不会被执行的。这也就是为什么 <textarea> 标签不能用来进行 XSS 攻击的原因。

Cookie&Session

        Cookie 和 Session 是两种用于在客户端和服务器之间保存数据的方式。它们可以用来跟踪用户的状态、保存用户的信息，以及实现一些其他功能。

        Cookie 是一种存储在用户浏览器中的数据，由服务器发送到浏览器并保存在本地的文本文件中。浏览器会在每次向服务器发送请求时，自动在请求头中加上这些 Cookie 的信息。这样，服务器就能够识别出用户的身份，并进行相应的处理。

        Cookie 的优点在于它能够跨越多个浏览器会话，在用户访问网站的不同时间、不同页面时都能保持有效。但是，Cookie 也有一些缺点，比如：

1. Cookie 存储的数据量有限（通常是 4KB 左右）。
2. Cookie 保存的数据是明文的，不安全。
3. Cookie 可以被用户删除。

        Session 是服务器端的一种数据存储方式，用于在多个页面之间保存用户的状态。当用户访问网站时，服务器会为其分配一个唯一的 Session ID，并将这个 ID 保存在服务器端的内存中。然后，服务器会将这个 ID 发送到用户的浏览器，浏览器会将这个ID 保存在本地的 Cookie 中。在用户的后续访问中，浏览器会自动在请求头中加上这个 Session ID 的信息，服务器就能够识别出用户的身份，并进行相应的处理。

        Session 的优点在于它可以存储大量的数据，而且数据是保存在服务器端的，更加安全。但是，Session 的缺点也很明显，比如：

1.      1. Session 的有效期只在浏览器会话期间有效，一旦浏览器关闭，Session 就失效了。
2. Session 需要在服务器端为每个用户单独开辟内存空间，如果有大量的用户同时访问网站，会对服务器的性能造成较大的影响。