Web安全 – FoxDevelop

安全意识

jack — Thu, 20 Aug 2026 02:20:35 +0000

安全意识是程序员最重要的基本功。写代码时，永远要假设所有用户输入都是恶意的。
攻击入口主要集中在：表单提交、文件上传、URL参数、第三方解析引擎等位置。

1、文件上传漏洞风险

攻击者上传动态脚本文件，例如 aspx、php、asp 等服务端可执行页面。
之后直接访问上传后的脚本地址，代码会在服务器上运行。
危害：篡改网站首页、植入广告、删除服务器文件、获取服务器权限。

开发要点：文件上传模块必须做校验，限制文件类型，禁止上传服务端脚本。

2、表单与输入点

表单提交处不可信任用户输入：

需要过滤危险HTML、JS脚本，防范XSS跨站脚本；
SQL操作使用参数化查询，杜绝SQL注入；
第三方页面解析引擎，如果支持直接执行SQL，风险极高。
例如用户传入 select username，直接查询拿到全部账号数据。

3、错误提示信息模糊处理

不好示例：

“账号不存在”
“密码错误”

推荐模糊提示：

“账号或者密码或者验证码输入不对”

如果分开提示，黑客可以暴力枚举，先探测哪些账号是系统真实存在的，再爆破密码。模糊错误提示增加攻击者猜测难度。

4、登录防护

增加输入错误锁定功能，密码多次输错后进行账号锁定，防止暴力破解；
修改后台管理默认登录地址，不要使用通用路径（如 /admin），减少被扫描器探测到的概率。

5、URL参数校验

对URL传递的参数做校验过滤，不能直接拿来拼接SQL、直接输出页面，防止传入恶意参数发起攻击。

总结

安全不是靠某一个单独功能，而是融入每一行代码。
所有来自浏览器的数据（表单、上传文件、url参数、cookie）全部都不可信，都要做校验、过滤、处理。

前面学习的SQL注入、XSS、CSRF、文件上传，根源大多都是程序员缺少安全意识，直接信任用户输入。

钓鱼网站

jack — Thu, 20 Aug 2026 02:14:49 +0000

什么是钓鱼网站

钓鱼，通俗理解就像钓鱼捕鱼：不法分子伪装成用户信任的正规网站，引诱用户主动输入账号、密码、转账，让用户“上钩”，以此骗取个人信息与钱财。

钓鱼网站：仿冒银行、电商、门户等真实网站的页面样式，利用域名细微差别迷惑用户，骗取账号、密码、银行卡信息等私密资料，属于网络欺诈行为。

攻击案例

仿冒谷歌网站
真实域名：www.google.com
钓鱼域名：www.googel.com（字母仅有一处差别）
页面几乎复刻原版网站，弹出中奖提示，诱导用户转账参与所谓活动。
仿冒银行官网
页面布局、LOGO和真实银行网站几乎一模一样，欺骗用户输入银行卡账号、密码，黑客直接拿到用户的账户信息。

传播方式

通过邮件、短信、聊天消息发送伪装链接，点击跳转钓鱼网站。
也会利用真实网站漏洞，在正常网页插入恶意跳转代码，把用户引导到钓鱼页面。

钓鱼网站特点

页面外观和正规网站高度相似；
URL域名和真实域名存在细微差异（字母写错、增加字符）；
网站结构简单，往往只有少数几个页面，核心目的就是收集用户输入的敏感信息；
诱导用户输入账号、密码、银行卡、验证码等隐私数据。

带来的危害

窃取账号密码、银行卡信息，造成财产损失；大量钓鱼网站泛滥，损害电商、金融线上业务，打击大众使用互联网服务的信心。

防范手段

仔细核对浏览器地址栏域名，不要只看页面样子，不点击陌生短信、邮件发来的链接；
重要网站尽量手动输入域名访问，不直接点开外部链接；
开启安全防护软件（电脑管家等），软件可以识别拦截已知钓鱼网站；
正规机构不会通过网页索要验证码、银行卡密码，遇到要求填写敏感信息需要提高警惕。

XSS、CSRF、SQL注入：攻击网站服务器/网页漏洞。

钓鱼网站：主要欺骗普通用户本人，不是利用网站代码漏洞。

跨站请求伪造 CSRF

jack — Thu, 20 Aug 2026 02:11:35 +0000

什么是CSRF

CSRF全称 Cross‑Site Request Forgery，跨站请求伪造，也叫一键攻击、会话劫持攻击，属于被动攻击。

简单理解：攻击者盗用你的登录身份，以你的名义发送恶意请求。网站只校验Cookie确认身份，但无法判断这个请求是不是用户本人自愿发起的。

攻击前提（两个条件必须同时满足）

用户已经登录目标网站，浏览器本地保存网站登录Cookie，没有登出。
用户在同一个浏览器，打开新标签访问黑客准备的恶意网站。

攻击举例（模拟银行转账）

用户A登录银行网站，浏览器保存银行网站的Cookie。
用户A没有退出银行页面，又打开标签访问恶意网站B。
恶意网站B页面里面藏有恶意代码（隐藏图片、自动提交表单），偷偷向银行网站发送转账请求。
浏览器发起请求时，自动带上银行网站的Cookie。
银行服务器校验Cookie有效，误认为是用户自己操作，完成转账。

GET方式简单攻击示例

恶意页面内写一张看不见的图片，加载图片就自动触发转账请求：

<img src="http://www.mybank.com/Transfer.php?toBankId=11&money=1000" />

误区：改成POST请求不能解决CSRF，黑客可以用JS构造表单自动提交POST请求，依旧可以完成攻击。

安全漏洞扫描工具经常可以扫描出CSRF漏洞。

CSRF与XSS简单区分

XSS（跨站脚本）：注入恶意JS脚本，盗取Cookie，控制浏览器。
CSRF（跨站请求伪造）：不需要偷Cookie，直接利用浏览器自动携带Cookie的特性，冒充用户发请求。

CSRF解决方案（服务端防御为主）

1. CSRF‑Token 令牌方案（最主流有效）

服务器为用户会话生成一个随机不可预测的Token，存放在Session中。
页面表单增加隐藏域，把这个Token嵌入页面一起返回浏览器。
用户提交表单的时候，必须带上这个Token。
服务器校验提交上来的Token和Session保存的Token是否一致；不一致直接拒绝请求。

黑客的恶意网站无法获取到这个随机Token，就无法伪造合法请求。

2. Cookie设置SameSite属性

设置Cookie的SameSite=Lax / SameSite=Strict，浏览器在跨站场景下不会自动携带Cookie，从源头抑制CSRF攻击。

3. 校验请求来源 Referer / Origin

服务器检查HTTP请求头，判断请求来源域名是否为本网站；拒绝来自外部站点的请求。

缺点：部分浏览器可以禁用Referer，只能做辅助防护，不能单独依靠该方案。

4. 高危操作二次校验

转账、修改密码、修改重要资料等敏感操作，增加验证码、再次输入密码确认，就算请求被伪造，也无法完成操作。

补充：ASP.NET、Spring、Django等主流Web框架都内置CSRF防护功能，开发时需要手动开启。

DoS攻击与DDoS攻击

jack — Thu, 20 Aug 2026 02:07:11 +0000

DoS攻击（Denial of Service，拒绝服务攻击）

服务器有最大并发承载上限，举例：服务器最多同时处理100个访问请求。
IIS应用程序池存在队列长度配置，当并发请求超过该阈值，网站返回 503 服务不可用。

黑客（例如竞争对手）使用工具持续疯狂向网站发送大量请求。服务器无法区分请求是正常用户还是攻击流量，全部接收处理。服务器资源被占满，真实正常用户无法访问网站，服务瘫痪，以此达到破坏目的。

DoS：单台机器发起攻击，消耗服务器CPU、内存、连接数，让正常用户拒绝访问。

DDoS攻击（分布式拒绝服务攻击）

DoS的升级版，分布式。
不是一台电脑攻击，黑客控制大量肉鸡（多台主机、大量设备），成千上万台机器同时发起请求，流量规模远大于普通DoS，杀伤力更强。

攻击效果

CPU、内存、带宽占满
IIS程序池队列打满，出现503
网站响应极慢、直接打不开

简单区分

DoS：单点（一台主机）攻击服务器
DDoS：分布式，大量机器同时攻击，流量更大，更难防御

解决方案

部署防护软件，例如安全狗等Web防护工具，做流量拦截、限制单IP请求频率。
硬件/云服务商高防：云厂商高防IP，抵御大流量DDoS攻击（软件很难对抗超大流量DDoS）。
IIS层面配置：限制程序池队列长度、设置IP限流，缓解小规模DoS。
CDN加速：网站流量先经过CDN节点，攻击流量被CDN清洗，再转发源站。

注意：普通软件防护只能抵御小规模DoS；面对大流量DDoS，单纯服务器本地软件很难扛住，需要依靠云高防服务。

跨站脚本攻击（XSS）

jack — Thu, 20 Aug 2026 02:04:12 +0000

什么是XSS

英文全称：Cross‑Site Script，为了和CSS（层叠样式表）区分，缩写命名为 XSS。

攻击常发生在允许输入HTML内容的位置：评论区、CMS投稿、用户留言等。
黑客以普通用户身份，提交包含恶意JS脚本的HTML代码。其他用户访问页面时，恶意脚本会在浏览者浏览器中执行。

典型危害：
脚本可以读取当前用户的Cookie，并把Cookie发送给黑客。黑客拿到Cookie即可冒充账号登录；如果窃取到管理员Cookie，就可以获取网站管理员权限。

早期XSS案例大多是跨域场景，因此叫“跨站脚本”；现在即使不跨域，也可以实施攻击，但XSS名称保留沿用。

XSS两种常见类型

反射型XSS
恶意代码放在URL参数里，请求触发后直接在页面输出，不会存入数据库，需要诱导用户点击恶意链接才会触发。
存储型XSS
恶意脚本提交后保存到数据库（评论、投稿），所有访问该页面的用户都会触发脚本，危害更大。

ASP.NET WebForm 反射型XSS演示示例

页面 WebForm1.aspx

<body>
    <form id="form1" runat="server">
        <div>
            <asp:Literal ID="Literal1" runat="server">asp:Literal>
        div>
        <div>
            <asp:TextBox ID="TextBox1" runat="server">asp:TextBox>
            <asp:Button ID="Button1" runat="server" Text="Button" OnClick="Button1_Click" />
        div>
    form>
body>

后端按钮事件，直接把用户输入原样输出到页面，就会产生XSS漏洞：

protected void Button1_Click(object sender, EventArgs e)
{
    //漏洞：直接把用户输入渲染为HTML
    Literal1.Text = TextBox1.Text;
}

用户输入：，提交后脚本直接执行。

XSS 解决方案

输入过滤（保存数据库之前处理）
过滤危险标签与事件：

JS事件：onclick、onload、onmouseover
危险属性：style、expression、background:url(javascript:...) 等，清除可执行JS的代码。

使用UBB编辑器
不直接保存HTML，转成UBB标记语法。只保留安全排版功能，自动禁用JS事件、危险脚本。
业务上尽量不要开放HTML输入权限
如CMS投稿、评论模块，非必要不要支持完整HTML。
输出编码（重要）
把用户输出内容做HTML编码，< > " '转义成实体字符，浏览器只会当成普通文本展示，不会解析执行脚本。

配合Cookie设置HttpOnly=true，就算XSS漏洞出现，JS脚本也无法读取Cookie，降低损失。

Cookie的安全问题

jack — Thu, 20 Aug 2026 02:00:06 +0000

Cookie作用

Cookie用来保存用户身份信息。浏览器访问服务器时，会自动把Cookie随请求一起发送给服务端，服务器依靠Cookie识别用户。

举例子：登录谷歌
登录成功后，谷歌服务器向浏览器写入Cookie。后续每次访问谷歌页面，浏览器自动带上Cookie，服务器解析Cookie，就知道是哪个已登录用户。

安全风险

如果Cookie被窃取、拷贝到攻击者电脑，攻击者拿着这份Cookie去访问网站，就可以冒充你的账号登录。
另外页面中的JS脚本，如果存在XSS漏洞，也可以通过JavaScript读取到Cookie，把Cookie发送给黑客，盗取用户身份。

解决方案：HttpOnly 属性

服务器设置Cookie时，加上 HttpOnly=true。

注意：不是仅本台电脑可读。

JavaScript无法读取该Cookie，防止XSS脚本窃取Cookie；

Cookie依旧会在浏览器HTTP请求时自动发送到服务器；

浏览器本身可以携带、使用这个Cookie，但是JS脚本拿不到Cookie内容。

补充常用安全属性

HttpOnly=true：禁止JS读取Cookie，抵御XSS偷Cookie
Secure=true：只有HTTPS加密访问的时候，才会发送Cookie，http明文请求不会携带
SameSite：防止跨站请求伪造CSRF攻击

HttpOnly 不能防止别人复制你的浏览器Cookie文件（别人直接来到你的电脑旁边，通过U盘拿你的Cookie）。如果别人拿到你本地浏览器完整Cookie文件，依旧可以冒充登录；它主要防护网页JS脚本窃取Cooki这一类攻击。

设置示例（C#）

HttpCookie cookie = new HttpCookie("userToken");
cookie.Value = "登录身份凭证";
cookie.HttpOnly = true;   // 开启HttpOnly，JS不可读取
cookie.Secure = true;
Response.Cookies.Add(cookie);

密码安全

jack — Thu, 20 Aug 2026 01:56:10 +0000

Web安全之密码安全

禁止存储明文密码

不要把用户原始密码直接保存到数据库。

例子，用户注册填写密码 123321

错误做法：数据库直接存明文 123321
正确做法：对密码做哈希加密，保存加密后的字符串，例如：dsfdsfwrefdsfa32efsfdsfds

疑惑：加密之后登录时密码不就对不上了吗？
我们不需要解密拿到原始密码。
登录逻辑：用户输入的密码，使用和注册时完全相同的哈希算法再加密一次，拿登录加密后的结果，和数据库里存储的加密字符串做比对即可，两者相等代表密码正确。

流程：

MD5 的缺陷

早期经常使用 MD5 做密码哈希，单纯MD5并不安全。
网上有网站直接通过穷举法把大量的随机密码和对应的密码的MD5事先保存到数据库中，可以直接反向破解简单密码，容易被撞库。

加盐（Salt）处理

加盐：密码拼接一段随机字符串（盐值）之后，再执行加密，大幅提升破解难度。

示例：

MD5(用户密码 + 盐值)
MD5(pwd + "stat")

要点

盐值不要写死固定字符串，最好每个用户使用独立随机盐；
盐值也需要存储在数据库，登录时取出同一个盐，和用户输入密码再一起哈希；
生产环境优先使用 BCrypt、PBKDF2、Argon2，比MD5加盐更加适合密码存储。

业务流程

用户注册：拿到密码，生成随机盐 → 哈希(密码+盐) → 密文+盐一起入库
用户登录：拿到输入密码，读取该用户数据库的盐 → 哈希(输入密码+盐)，和数据库密文对比，相等即校验通过。

SQL注入攻击

jack — Thu, 20 Aug 2026 01:52:09 +0000

网站登录场景：用户输入账号、密码提交到服务端校验。
示例正常输入：

账号：admin
密码：123456

程序员直接拼接字符串生成SQL语句：

select * from user where name = 'admin' and password = '123456'

数据库查询到记录，则登录成功；查无记录则拒绝登录。

SQL注入攻击演示

黑客在密码输入框恶意输入：

123456' or '1'='1

程序直接拼接后最终执行SQL：

select * from user where name = 'admin' and password = '123456' or '1'='1'

'1'='1' 条件恒成立，整条SQL查询永远返回数据，黑客不需要正确密码即可登录系统。

直接把用户输入当做SQL代码拼接，用户可以篡改SQL语义。

解决方案：参数化查询

不要拼接用户输入，使用 ADO.NET SqlParameter 参数化查询，用户输入只会被当做普通字符串值，不会被解析成SQL指令。

C#示例代码：

StringBuilder strSql = new StringBuilder();
strSql.Append("select * from user where name = @name and password = @pwd");

SqlParameter[] parameters = {
    new SqlParameter("@name", SqlDbType.Nvarchar,50),
    new SqlParameter("@pwd", SqlDbType.Nvarchar,50)
};
parameters[0].Value = name;
parameters[1].Value = pwd;

return DbHelperSQL.Exists(strSql.ToString(), parameters);

注意

SQL语句里参数不要加单引号：@name，不能写成 '@name'
用户输入全部赋值给SqlParameter对象，禁止直接拼接进SQL字符串
底层数据库驱动会自动处理特殊符号，彻底抵御SQL注入。