惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

G
Google Developers Blog
博客园 - 聂微东
J
Java Code Geeks
Engineering at Meta
Engineering at Meta
Jina AI
Jina AI
D
Docker
B
Blog
S
SegmentFault 最新的问题
宝玉的分享
宝玉的分享
D
DataBreaches.Net
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Y
Y Combinator Blog
N
Netflix TechBlog - Medium
月光博客
月光博客
F
Fortinet All Blogs
爱范儿
爱范儿
H
Help Net Security
腾讯CDC
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
WordPress大学
WordPress大学
The Cloudflare Blog
有赞技术团队
有赞技术团队
T
Tailwind CSS Blog
U
Unit 42

Surmon.me

一人有限集团 你就是不敢 创造力是温柔的谎言 人类正在退出人类 AI 代替不了这样的你 脉冲点火背后的架构设计 基于 Cloudflare 生态的 AI Agent 实现 NodePress 支持用户登录了 从统计学习到通用智能 2025 投资报告:走慢的路 无依之地 会杀人的菩萨 无我不是共识 文化的积重与偏见 当下即安 科学的尽头是态度 无我不是 Egoless 信仰不因恐惧而存在 世间无解的矛与盾 先别急着做些什么 佛不需要你的皈依 真理的幻觉 两扇大门 造心里的浮屠 自胜者强 逻辑与智慧 真的相 快乐的秘密 只需愿意 是名体验
常见的 Web 安全问题
Surmon · 2017-05-07 · via Surmon.me

总结几种常见的 Web 安全问题,及解决方法。

XSS

跨站脚本攻击(XSS, Cross-site scripting)

简单说:在没有防范用户输入的情况下,用户输入了预期之外的数据,此数据再次输出时便对客户端造成了威胁。

举个例子:评论框,若未过滤用户输入内容,用户输入 JavaScript 脚本后添加至评论数据表,再次输出评论列表时,此脚本将可以被执行,脚本内容可能是窃取 cookie、窃取 token、监听登录事件截获数据发送至指定地址...

解决方法:永远不要相信用户输入的。

  • 输入时拦截:输入时对数据进行规范转义,客户端和服务端等各个节点都需要执行。
  • 输出时转义:输出时过滤不合法标签/代码后再解析为 HTML,或不使用 HTML,如果可以的话。

CSRF

跨站请求伪造(CSRF, Cross-site request forgery)

简单说:攻击者通过伪造一个合法的请求(跨站)、或钓鱼连接(非跨站),来达到自己的目的。

发生条件:

  • 攻击者了解被攻击的系统的请求机制
  • 目标站具有拥有目标站权限的持久化 cookie 或被攻击者会话中 cookie
  • 目标站对于目标事务不会进行二次授权

举个例子:

WordPress 较低版本的程序后台,从文章列表删除一篇文章,在点击删除按钮后,后台会发起一个 get 请求去执行删除, 因为 WordPress 的开源和开放,这个 get 请求的构造非常容易被拿到,文章 id 就是直接暴露的,假设攻击者知道了请求的 API 地址和文章 id, 攻击者可以在任何地方布置下这个链接,只要你点击这个链接,这个删除的 get 请求就会附带你的持久化 cookie(如果有的话),攻击者的目的便达成了; 以此类推,这个链接可以是重置整站、删除某用户...

所以,CSRF 攻击的核心是利用了 Cookie 允许跨域的特性,不受空间的限制,从而造成攻击; 在上面的例子里,我们甚至可以在一个攻击者布置的网站里放置一个 img 标签,src 设置为目标地址,目的也可以达到,只要被攻击者打开这个网站,请求便会自动被执行。

解决方法:

  • 检查 Referer 字段
  • 规范化 API 设计,get 就只是请求资源
  • 任何用户输入的地方,布置一次性 token,用于验证请求的真实性、有效性
  • Cookie 改用 JWT token,存储至 localStorage,localStorage 禁止跨域读取数据

SQL注入

简单说:把 SQL 语句通过 Web 上的漏洞注入到服务端去执行,以达到目的。

发生条件:

  • 已被攻击者探测出服务端对用户查询/输入的过滤级别
  • 已被攻击者探测出数据库类型
  • 已被攻击者探测出数据表结构

举个例子:

  • 服务端预期输入:www.sample.com?testid=23
  • 攻击者实际输入:www.sample.com?testid=23'or'23'='23
  • 或者更狠的:www.sample.com?testid=23or1=(select count(*) from job)--
  • 或者...

解决方法:永远不要相信用户输入的。

  • 对用户的输入进行校验,对敏感符进行转义
  • 避免使用动态拼装 SQL 语句,可以使用参数化的 SQL 或直接使用存储过程进行数据查询存取
  • 避免使用管理员权限的数据库连接,为应用单独开辟权限
  • 敏感信息务必加密
  • 生产环境尽量减少异常信息的输出,最好使用自定义的错误信息对原始信息进行包装

其他的,常识性漏洞,或者我觉得不严重的,就不说了... 或者之后再补充。