一文读懂 Web 安全

Posted 前端日志

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一文读懂 Web 安全相关的知识,希望对你有一定的参考价值。

Web 安全是互联网中不可或缺的一个领域,这个领域中诞生了大量的黑帽子与白帽子,他们都是安全领域的王者,在平时里,他们利用各种巧妙的技术互相博弈,时不时就会掀起一场 Web 安全浪潮,真可谓神仙打架,各显神通。

本文从一个吃瓜群众的角度,聊一聊 Web 安全的一些有趣故事。

  • 安全世界观
  • 安全攻防案例
  • 总结与思考
  • 在互联网发展之初,IE 浏览器垄断的时期,大家上网的目的都很单纯,主要通过浏览器分享信息,获取新闻。但随着互联网的不断发展发展,一个网页能做的事情越来越多,除了看新闻,我们还可以看视频、玩游戏、购物、聊天等,这些功能都大大丰富了我们的生活。

    随着网页功能的逐渐增多,就开始出现了一些黑帽子,他们试图通过一些技术手段来牟取利益。在我小的时候,印象最深的就是木马病毒,它可以监控你的键盘,将你在键盘上敲打的内容发送到黑客的机器上,黑客通过分析这些内容,很容易就能得到你的游戏账号和密码。

    在这之后,就诞生出了一些杀毒软件,致力于解决网络上的各种病毒,随着不断地发展,杀毒软件已经成为一台电脑必不可少的软件。

    为什么会出现这样的安全问题?

    安全归根到底是信任的问题,如果所有人都按照正常的流程去上网,不去谋取私利,也就没有安全问题可谈了。

    安全的根本在于信任,但要让所有人互相信任谈何容易。在当前阶段,我们可以做到:持续做好安全防护,让漏洞越来越少,非法攻击越来越困难,这样就能逐渐减少黑帽子的数量,让病毒制造者越来越少。

    文件夹下的目录,如果有人想删库跑路,在执行 rm -rf / 时,就会提示无权限。
  • 纵深防御原则
  • 这条原则类似 木桶理论,安全水平往往取决于最短的那块板。
  • 即:不要留下短板,黑帽子们往往可以利用短板为突破口,挖掘更大的漏洞。
  • 数据与代码分离原则
  • 当用户数据被当成代码执行时,混淆了数据和代码的边界,从而导致安全问题。
  • 如:XSS 就是利用这一点去攻击的。
  • 不可预测性原则
  • 这条原则是为了提高攻击门槛,有效防止基于篡改、伪造的攻击。
  • 如:数据库中使用 uuid 代替 number 型的自增主键,可以避免 id 被攻击者猜到,从而进行批量操作。
  • token 也是利用不可预测性,攻击者无法构造 token 也就无法进行攻击。
  • 有了这些安全原则,我们就可以开干了,接下来介绍几个常见的攻防案例。

    安全攻防的案例非常多,这里主要介绍几个出镜率比较高的安全问题。

    的用户名,所有能看到此用户名字的页面,都会弹出当前浏览器的 Cookie,如果代码的逻辑是将 Cookie 发送到攻击者的网站,攻击者就能冒充当前用户进行登录了。

    XSS 攻击方式有很多,所有和用户交互的地方,都有可能存在 XSS 攻击。

    例如:

  • 所有 input 框。
  • window.location。
  • window.name。
  • document.referrer。
  • document.cookie。
  • localstorage。
  • ...
  • 由于页面中与用户交互的地方非常多,肯定还有一些 XSS 的攻击方式没有被发现,而一旦被黑帽子发现,就可能造成严重的影响,所以我们务必引起重视。

    如果表明猜对了,就延迟 10 s 并返回成功。
  • 使用存储过程执行系统命令
  • 通过内置的方法或存储过程执行 shell 脚本。
  • 如:xp_cmdshell、sys_eval、sys_exec 等。
  • 字符串截断
  • 如:mysql 在处理超长的字符串时,会显示警告,但会执行成功。
  • 注册一个 admin + 50 个空格的用户,会触发截断,最终新增一个 admin 用户,这样就能拥有管理员权限了。
  • 能绕过后缀名检查,但在执行时,被当成一个 php 文件进行执行。
  • IIS 会截断分号进行解析
  • 如:abc.asp;xx.png 能绕过后缀名检查,但在执行时,被当成一个 asp 文件进行执行。
  • HTTP PUT 方法允许将文件上传到指定位置
  • 通过 HTTP MOVE 方法,还能修改上传的文件名。
  • 通过二者配合,就能先上传一个正常的后缀名,然后改为一个恶意的后缀名。
  • PHP CGI 路径问题
  • 执行 http://abc.com/test.png/xxx.php 时,会把 test.png 当做 php 文件去解析。
  • 如果用户正好是把一段恶意的 php 脚本当做一张图片进行上传,就会触发这个攻击。
  • 本文介绍了 Web 安全的基本概念,以及大量的攻防技巧,其实这只是 Web 安全中的冰山一角,如果你对此感兴趣,不妨在安全领域继续深耕学习,一定能看到更广阔一片天。

    对于一个开发者来说,我们应该在写代码时就将安全考虑其中,形成自己的一套安全开发体系,做到心中有安全,时时考虑安全,就能无形之中化解不法分子的攻击。

    最后,如果你对此有任何想法,欢迎留言评论!

    你点的每个在看,我都认真当成了喜欢

    安全之心:一文读懂可信计算

    简介: 信 or 不信,这是个问题

     

    可信计算
    TC (Trusted Computing)
    业界新宠,越来越被高频提到
    本质是
    创造可信执行环境的芯片级安全防护方案

    然而,江湖流传 TA 的传说
    却鲜少有人见过真身
    阿里云作为亚太区最早布局可信计算的云厂商
    今天我们一起来聊聊 TA 是谁?

     

    一、环境可信

    “把大象放入冰箱需要几步”

     

    如何通过“信任链”建立可信执行环境
    可以分为三步来理解它

    • 可信根
    • 可信链
    • 度量/验证

    第一步
    可信根:芯片级、底层、不可篡改

    芯片级硬件的不可篡改性
    决定了其可以作为最高等级安全的基础
    再将硬件层安全虚拟映透传整个目标环境
    形成软硬结合的安全体系

     

    1.JPG

     

    一台电脑组件来自四面八方
    包括他的主板芯片
    当你打开电脑的时候
    可能同时唤醒了隐藏在启动链路上的后门
    Rootkit/Bootkit

    可信硬件的插入
    病毒无法篡改系统原设计
    快速发现Rootkit/Bootkit并及时处理

    可信根
    对密钥等私密数据进行物理保护
    参与建立并保障可信链的传递
    对可信芯片进行安全调用

     

     

    面对深度隐藏且难以察觉的威胁
    需要来自底层的保护
    保障上层的不可篡改性

     

     

    此处
    引入一个比喻来加深一下理解

    工人把半成品交给下一个工人
    为了工作顺利完成
    首先需要保证
    工作链条是在可信的前提下推进着……

     

    2.JPG
    3.JPG

     

    方法一

    每个工人在交出去之前
    检查下一个工人是否为内部人士

    注:第一个工人很重要
    如果其身份造假
    后面的工作都是错误的
    此时第一位工人就是信任根
    其参与建立并决定可信链的传递

     

    4.JPG

     

    方法二

    流水线保持流动
    每一次交付都记录下来

    注:每次交付的记录本身很重要
    保证这个记录不被篡改
    记录就像密钥一样存储在可信根

    把 TA 作为整个安全的可信起点
    对不可控的软硬件实体实现管理

    那么
    问题来了
    如何完成从可信起点到应用、到网络的透传?

     

     

    两步并作一步:
    信任链与验证/度量结果
    说好的三步变两步
    此处我失去了一点你的信任

     

     

    此处,
    我们又故作神秘的引入一个历史故事

    战国“策”

     

    5.JPG

     

    秦攻打赵
    魏信陵君希望魏王出兵营救

    信陵君
    通过通关密文进了魏王殿
    通过使者找到了魏王妃
    通过魏王妃拿到兵符
    (一半的玉佩)
    通过兵符配对
    (与将军手里的兵符契合成功)

     

    6.JPG
    7.JPG

     

    历史上的信陵君成功调用兵力
    这是一个中性的信任关系的传递
    因为其未经验证
    不可信的人完成了整体关系的传递

     

     

    如果
    关系链起点和传递过程
    经过验证与及时异常行为管理
    兵符并不会这么轻易被拿走
    所以
    验证/度量结果的重要性不容忽视

     

     

    同样是这个故事
    我们换成当代可信环境下验证思考
    会有不同的结局
    当信陵君进魏王殿
    守卫发现其并非白名单成员

     

    8.JPG

     

    再比如
    信陵君见到魏王妃
    王妃验证目的:
    你要偷兵符
    上报魏王

     

    9.PNG

     

    或者
    最后就算信陵君拿到兵符
    魏王有及时发现兵符丢失的敏感机制
    并及时甚至提前通报将军
    “谁拿着兵符来找你就杀了他”

     

    10.PNG

     

    这是有可信根参与的
    经过度量值比对的可信链

    可信计算的核心功能
    是基于可信硬件建立主动免疫机制
    核心流程是可信根通过可信链链接各应用
    过程经过度量值比对
    将信任关系逐渐扩展至整机乃至网络

     

    二、隐世高手

    可信计算神龙见首不见尾?

     

    历史上真实发生的“窃符救赵”
    更贴近传统IT架构下安全产品和服务的部署
    想要实现可信计算环境
    并不容易

    一个相对重要的计算环境
    为了保障处于可信环境
    至少需要面对以下问题

     

    • 懂芯片
    • 懂硬件
    • 懂固件
    • 懂虚拟技术
    • 懂可信链
    • 懂软硬结合
    • 懂……

    11.JPG

     

    一边是啥也不懂很难
    一边是啥都懂了的阿里云

     

     

    现在
    阿里云“拿捏住了”这个点:
    可信内置在基础设施中
    云管理物理机运行环境可信
    阿里云可以按需对云虚拟服务器提供可信服务
    BIOS、引导程序、操作系统内核、
    应用程序加载等进行度量/验证
    不需要用户采购组件

    1、系统可信:
    云上物理机和虚拟机运行环境
    即操作系统的可信
    2、应用可信:
    云上管理应用和用户侧应用可信

     

    三、安全可信

    云环境比以往任何计算环境
    都需要安全可信

     

    场景一

    数据上云
    数据不在自己眼前
    而在远程存储
    用户需要确认远程的存储环境是否可信

     

    12.PNG

     

    可信前:
    存储之后
    东西被黑了

    可信后:
    远程证明
    可以远程确认储存/计算环境可行性

     

     

    场景二

    APT等高等级攻击威胁不断升级

     

    13.JPG

     

    黑客疯狂攻击
    手段变幻莫测
    惊叫“这是什么新手段”

    单点防御传统安全思路照搬到云环境
    必然面临水土不服的窘境

    可信计算方案
    则是将防护前置
    这也是更有前瞻性的安全技术
    任你千变万化,我以不变应万变

     

    14.JPG

    可信云服务方案示意图

     

     

    启动时
    通过可信启动机制
    对系统程序和引导程序等
    进行可信验证以及控制

    运行时
    通过贯穿固件和软件各层面的可信软件基
    对软件执行的关键环节
    例如进程启动、文件访问和网络访问等
    进行拦截和判定

    审计上报
    所有报警均上报云运维监控平台
    或用户侧的云安全中心

     

     

    切勿浮沙筑高台
    将安全建立在硬件的不可篡改性
    与密码学的理论安全性之上

     

     

    关于可信计算的实际应用:
    构筑企业级可信计算环境

     

     

    远程证明:

    基于数字签名安全上报度量结果
    可靠证明系统启动与运行状态
    动度量的状态作为远程证明依据

    零信任密钥管理与密码算法应用:

    vTPM/vTCM(虚拟可信模块)
    提供完备的密钥管理与密码算法功能
    因此依托vTPM
    ECS环境可在启动时
    第一时间可靠的创建密钥、申请证书
    并执行数字签名与加解密等运算

     


     

    最后
    我们不妨再做一个令人兴奋的假设:

    此时你拥有500万流动资金
    在开心之余
    这笔钱的安全问题也给你带来了幸福的烦恼
    这笔财富放在哪?
    家里和银行怎么选?

     

    16.JPG
    17.JPG

     

    选择
    银行中专业的保险箱
    还是
    家里普通的柜子

    相当于
    云上网络、主机等各方面系统化的
    安全防护机制
    vs
    个人安装的杀毒软件

     

    18.JPG

     

    选择银行卡
    还是现金

    相当于
    云上专业完善的数据安全机制
    vs
    个人简陋单一的口令机制

     

    19.JPG

     

    而且
    服务方面银行专职的保安与柜员
    对比
    家里普通家庭成员

    相当于
    云上态势感知服务与专业安全专家运
    vs
    个人非专业的安全知识

    综上

    多数人都会选择把这笔巨款存放银行
    这就好比传统架构与云上架构对比
    从平台、数据、服务三个维度
    为云上客户提供可信与安全

    原文链接

    本文为阿里云原创内容,未经允许不得转载。

    以上是关于一文读懂 Web 安全的主要内容,如果未能解决你的问题,请参考以下文章

    《白帽子讲WEB安全》学习笔记之第3章 跨站脚本攻击(xss)

    《白帽子讲WEB安全》学习笔记之第7章 注入攻击

    《白帽子讲Web安全》笔记1-5章

    白帽子讲Web安全 第三章 跨站脚本攻击(XSS)

    《白帽子讲WEB安全》学习笔记之第13章 应用层拒绝服务攻击

    《白帽子讲WEB安全》学习笔记之第11章 加密算法与随机数

    (c)2006-2024 SYSTEM All Rights Reserved IT常识