3. 互联网安全架构

2020-06-15 本文已影响0人格林哈

1. 常见的Web攻击手段

l.1 XSS(Cross Site Scripting)攻击

原理
- 攻击者在网页中嵌入恶意脚本程序，当用户打开该网页时，脚本程序便开始在客户端的浏览器上执行，以盗取客户端cookie、用户名密码，下载执行病毒木马程序，甚至是获取客户端admin权限等。
例子
系统提交的字段输入 <script>恶意脚本</script>。查看这个字段，这个脚本就会执行。
防范
- 对用户输入的数据进行HTML转义处理，将其中的“尖括号”、“单引号”、“引号” 之类的特殊字符进行转义编码
- HTML字符转义

1.2 CSRF(cross site request forgery)攻击

原理
- image.png
- 攻击者完成csrf步骤
  - 登录受信任站点A，并在本地生成cookie；
  - 在不登出站点A（清除站点A的cookie）的情况下，访问恶意站点B。
防范
- 将cookie设置为HttpOnly
  - 含义是否能通过 js 去访问
  - Servlet API
    - ```
    response.setHeader( "Set-Cookie", "cookiename=cookievalue;HttpOnly");
```
- 加token。
  - 关键在请求中放入攻击者所不能伪造的信息，并且该信息不存在于cookie之中， token 不存token 放表单，后台验证。
- 通过Referer识别
  - 记录了该HTTP请求的来源地址
  - 在通常情况下，访问一个安全受限的页面的请求都来自于同一个网站

1.3 SQL注入攻击

原理
- 把SQL命令伪装成正常的HTTP请求参数，传递到服务端，欺骗服务器最终执行恶意的SQL命令，达到入侵目的
防范
- 使用预编译语句。
  - 在创建PreparedStatement对象时就指定了SQL语句，该语句立即发送给DBMS进行编译，当该编译语句需要被执行时，DBMS直接运行编译后的SQL语句
- 使用ORM框架
  - IBATIS 通过#符号配置的变量，iBATIS能够对输入变量的一些关键字进行转义，防止SQL注入攻击
- 避免免密码明文存放
- 处理好相应的异常
  - 后台的系统异常，很可能包含了一些如服务器版本、数据库版本、编程语言等信息，甚至是数据库连接的地址与用户名密码，攻击者可以按图索骥，找到对应版本的服务器漏洞或者数据库漏洞进行攻击

# 使用预编译语句
 String sql = "select * from hhuser where nick = ? and passwords = ? ";
    PreparedStatement st = conn.prepareStatement(sql);
    st.setString(1, nickname);
    st.setString(2, password);
    ResultSet rs = st.executeQuery();

1.4 文件上传漏洞

原理
- 恶意攻击者利用一些站点没有对文件的类型做很好的校验，上传了可执行的文件或者脚本，并且通过脚本获得服务器上相应的权利，或者是通过诱导外部用户访问、下载上传的病毒或木马文件，达到攻击的目的
- 为了防范用户上传恶意的可执行文件和脚本，以及将文件上传服务器当做免费的文件存储服务器使用，我们需要对上传的文件类型进行白名单校验，并且限制上传文件的大小，上传的文件需要进行重新命名，使攻击者无法猜测到上传文件的访问路径。
预防
- 通过魔数来判断文件类型
- 图片类型的文件，可以在上传后，对图片进行相应的缩放，破坏恶意用户上传的二进制可执行文件的结构，来避免恶意代码执行
  - imagemagick 是一套功能强大、稳定并且开源的针对图片处理的开发工具包，能够处理多种格式的图片文件，可以利用imagemagick来对图片进行缩放处理

1.5 DDos(Distributed Denial of Service)攻击

定义
- 分布式拒绝服务攻击，是目前最为强大、最难以防御的攻击方式之一
- 攻击者借助公共网络，将数量庞大的计算机设备联合起来作为攻击平台，对一个或多个目标发动攻击，从而达到瘫痪目标主机的目的
  - 通常在攻击开始前，攻击者会提前控制大量的用户计算机，称之为“肉鸡”，并通过指令使大量的肉鸡在同一时刻对某个主机进行访问，从而达到瘫痪目标主机的目的。
常见DDoS攻击手段
- SYN Flood 是互联网最经典的攻击方式之一
  - 攻击原理
    - TCP 三次握手的过程中设置了一些异常处理机制,建立连接第三步，客户端没有ACK返回，服务端一般会进行重试.也就是再次发送SYN+ACK报文给客户端，并且一直处于SYN_RECV(同步收到)状态，将客户端加入等待列表。重发一般会进行3～5次，大约每隔30秒左右会轮询一遍等待队列，重试所有客户端；另一方面，服务器在发出SYN+ACK报文后，会预分配一部分资源给即将建立的TCP连接，这个资源在等待重试期间一直保留，更为重要的是，服务器资源有限，可以维护的等待列表超过极限后就不再接收新的SYN报文，也就是拒绝建立新的TCP连接。
    - 利用了TCP协议三次握手的过程来达成攻击的目的。攻击者伪造大量的IP地址给服务器发送SYN报文，但是由于伪造的IP地址几乎不可能存在，服务端将维护一个非常大的半连接等待列表，并且不断对这个列表中的IP地址进行遍历和重试，占用了大量的系统资源。更为严重的是，由于服务器资源有限，大量的恶意客户端信息占满了服务器的等待队列，导致服务器不再接收新的SYN请求，正常用户无法完成三次握手与服务器进行通信。
- DNS Query FIood
  - 攻击原理
    - 向被攻击的服务器发送海量的域名解析请求。通常，请求解析的域名是随机生成的，大部分根本就不存在，并且通过伪造端口和客户端IP，防止查询请求被ACL过滤，被攻击的DNS 服务器在接收到域名解析，大量不存在的域名解析请求给服务器带来了很大的负载，当解析请求超过一定量时，就会造成DNS服务器解析域名超时
- CC攻击（攻击者借助代理服务器生成指向受害主机的合法请求，实现DDOS和伪装）
  - 攻击原理攻击者通过控制的大量“肉鸡”或者利用从互联网上搜寻的大量匿名的HTTP代理，模拟正常用户给网站发起请求直到该网站拒绝服务为止。大部分网站会通过CDN以及分布式缓存来加快服务端响应，提升网站的吞吐量，而这些精心构造的HTTP请求往往有意避开这些缓存，需要进行多次DB查询操作或者一次请求返回大量的数据，加速系统资源消耗，从而拖垮后端的业务处理系统，甚至连相关存储与日志收集系统也无法幸免。
  - CC攻击并不需要攻击者控制大量的“肉鸡”，取而代之的是互联网上十分容易找到的各种HTTP代理，肉鸡”由于流量异常，容易被管理人员发现，攻击持续时间难以延续，而使用HTTP代理则使攻击者能够发起持续高强度的攻击。攻击在应用层发起，往往又与网站的业务紧密相连，使得防守一方很难在不影响业务的情况下对攻击请求进行过滤，大量的误杀将影响到正常访问的用户，间接地达成攻击者的目的。

1.6 其他攻击手段

有DNS域名劫持、CDN回源攻击、服务器权限提升，缓冲区溢出，以及一些依赖于平台或者具体软件漏洞的攻击等，防御的滞后性使得攻击的手段永远都比防御的手段多

2. 常用的安全算法

2.1 数字摘要

一个单向Hash函数对消息进行计算而产生，对应一个消息或文本的固定长度的值。
特点
- 无论输入的消息有多长，计算出来的消息摘要的长度总是固定的如MD5 16字节
- 一般只要输入的消息不同，对其进行摘要以后产生的摘要消息也不相同，但相同的输入必会产生相同的输出
- 由于消息摘要并不包含原文的完整信息，因此只能进行正向的信息摘要，而无法从摘要中恢复出原来的消息，甚至根本就找不到任何与原信息相关的信息
常见算法
- MD5
  - 长度 16字节
- SHA(Secure Hash Algorithm)
  - 修订版 SHA-1 基于MD4算法现在已成为公认的最安全的散列算法之一
    - 长度为 20字节
- 十六进制
  - 计算机采用二进制的数据表示方法，16进制方便与二进制转换，也方便表示。
- Base64编码
  - 一种基于64个可打印字符来表示二进制数据的方法,由于2的6次方等于64，所以每6位为一个单元，对应某个可打印字符,三个字节有24位，对应于4个Base64单元，即3个字节需要用4个可打印字符来表示
  - Base64中的可打印字符包括字母A～Z、a～z、数字0～9，这样共有62个字符，此外两个可打印符号在不同的系统中而不同
- 彩虹表破解Hash算法
  - 一种破解哈希算法的技术，从原理上来说能够对任何一种Hash算法进行攻击
  - 简单地说，穷举法，彩虹表就是一张采用各种Hash算法生成的明文和密文的对照表，在彩虹表中，表内的每一条记录都是一串明文对应一种Hash算法生成的一串密文
  - 彩虹表法破解Hash算法原理

2.2 对称加密算法

数据发送方将明文（原始数据）和加密密钥一起经过特殊加密算法处理后，生成复杂的加密密文进行发送，数据接收方收到密文后，若想读取原文，则需要使用加密使用的密钥及相同算法的逆算法对加密的密文进行解密，才能使其恢复成可读明文
- image.png
特点
- 算法公开、计算量小、加密速度快、加密效率高。

        public static byte[] testMD5(String content) throws Exception {
            MessageDigest md = MessageDigest.getInstance("MD5");
            byte[] bytes = md.digest(content.getBytes("utf8"));
            return bytes;
        }
    
        public static byte[] testSHA1(String content) throws Exception {
            MessageDigest md = MessageDigest.getInstance("SHA-1");
            byte[] bytes = md.digest(content.getBytes("utf8"));
            return bytes;
        }

常用的对称加密算法包括DES算法、3DES算法、AES算法等
- DES算法
  - 背景 1975年3月17日，NBS公布了IBM公司提供的密码算法，以标准建议的形式在全国范围内征求意见。经过两年多的公开讨论之后，1977年7月15日，NBS宣布接受这个建议，将其作为联邦信息处理标准46号数据加密标准
  - DES算法属于对称加密算法，明文按64位进行分组，密钥长64位，但事实上只有56位参与DES运算（第8、16、24、32、40、48、56、64位是校验位，使得每个密钥都有奇数个1）,分组后的明文和56位的密钥按位替代或交换的方法形成密文。
- AES算法
  - 背景该算法由比利时密码学家Joan-Daemen和Vincent-Rijmen设计，结合两位作者的名字，又称Rijndael加密算法，是美国联邦政府采用的一种对称加密标准，这个标准用来替代原先的DES算法，已经广为全世界所使用，已成为对称加密算法中最流行的算法之一
  - AES算法作为新一代的数据加密标准，汇聚了强安全性、高性能、高效率、易用和灵活等优点，设计有三个密钥长度（128、192、256位），比DES算法的加密强度更高，更为安全
    - 由于美国对于加密软件出口的控制，如果使用192位和256位的密钥，则需要另外下载无政策和司法限制的文件，否则程序运行时会出现异常

2.3 非对称加密算法

需要两个密钥，一个称为公开密钥（public key），即公钥；另一个称为私有密钥（private key），即私钥。公钥与私钥需要配对使用，如果用公钥对数据进行加密，只有用对应的私钥才能进行解密，而如果使用私钥对数据进行加密，那么只有用对应的公钥才能进行解密。因为加密和解密使用的是两个不同的密钥，所以这种算法称为非对称加密算法
image.png
特点
- 对称加密算法中只有一种密钥，并且是非公开的，如果要解密就得让对方知道密钥，所以保证其安全性就是保证密钥的安全，而一旦密钥在传输过程中泄露，加密信息就不再安全。
- 对称加密算法中包含有两种密钥，其中一个是公开的，这样就不需要像对称加密算法那样，需要传输密钥给对方进行数据加密了，大大地提高了加密算法的安全性。非对称加密算法能够保证，即使是在获知公钥、加密算法和加密算法源代码的情况下，也无法获得公钥对应的私钥，因此也无法对公钥加密的密文进行解密。
- 非对称加密算法的复杂性，使得其加密解密速度远没有对称加密解密的速度快。为了解决加解密速度问题，人们广泛使用对称与非对称加密算法结合使用的办法，优缺点互补，达到时间和安全的平衡
  - 对称加密算法加密速度快，人们用它来加密较长的文件，然后用非对称加密算法来给文件密钥加密，解决了对称加密算法的密钥分发问题
常见算法
- RSA算法
  - 背景 1977年由Ron-Rivest、Adi-Shamirh和LenAdleman开发的，RSA取名来自他们三者的名字。RSA是目前最有影响力的非对称加密算法，它能够抵抗到目前为止已知的所有密码攻击，已被ISO推荐为公钥数据加密标准
  - 基于将两个大素数相乘十分容易，但反过来想要对其乘积进行因式分解却极其困难，因此可以将乘积公开作为加密密钥

2.4 数字签名

签名认证是对非对称加密技术与数字摘要技术的综合运用，指的是将通信内容的摘要信息使用发送者的私钥进行加密，然后将密文与原文一起传输给信息的接收者，接收者通过发送者的公钥解密被加密的摘要信息，然后使用与发送者相同的摘要算法，对接收到的内容采用相同的方式产生摘要串，与解密的摘要串进行对比，如果相同，则说明接收到的内容是完整的，在传输过程中没有受到第三方篡改，否则说明通信内容已被第三方修改。
每个人都有其特有的私钥，且都是对外界保密的，而通过私钥加密的信息，只能通过其对应的公钥才能解密。因此，私钥可以代表私钥持有者的身份，可以通过私钥对应的公钥来对私钥拥有者的身份进行校验
image.png
image.png

常见签名算法

MD5withRSA
- MD5算法生成正文摘要，RSA 算法进行正文加解密。
SHA1withRSA
- SHA-1 算法生成正文摘要，RSA 算法进行正文加解密。

2.5 数字证书

电子证书，类似于日常生活中的身份证，也是另外一种形式的身份认证，用于标识网络中的用户身份
证书自身带有公钥信息，可以完成相应的加密、解密操作，同时，还拥有自身信息的数字签名，可以鉴别证书的颁发机构，以及证书内容的完整性。由于证书本身含有用户的认证信息，因此可以作为用户身份识别的依据。
通常数字证书内容：
- 对象的名称（人、服务器、组织）
- 证书的过期时间
- 证书的颁发机构（谁为证书担保）
- 证书颁发机构对证书信息的数字签名
- 签名算法
- 对象的公钥
1 X.509
- 一种格式标准来规范数字证书的存储和校验。大多数的数字证书都以一种标准的格式（即X.509）来存储它们的信息
- iX.509所包含的证书字段
2 证书签发
- 网络用户的数字证书则需要由数字证书认证机构（Certificate.Authority，CA）来进行颁发，只有经过CA颁发的数字证书在网络中才具备可认证性。
- 签发过程实际上就是对数字证书的内容，包括证书所代表对象的公钥进行数字签名，而验证证书的过程，实际上是校验证书的数字签名，包含了对证书有效期的验证
- 证书签名的生成
- 国际权威数字证书认证机构的“三巨头”
  - VeriSign
  - GeoTrust
  - Thawte
3 证书验证
- 客户端接收到数字证书时，首先会检查证书的认证机构，如果该机构是权威的证书认证机构，则通过该权威认证机构的根证书获得证书颁发者的公钥，通过该公钥，对证书的数字签名进行校验
- 根证书
  - 根证书是证书认证机构给自己颁发的数字证书，是证书信任链的起始点，安装根证书则意味着对这个证书认证机构的信任。
- 证书校验的过程
- 要验证一份证书的真伪（即验证证书认证机构对该证书信息的签名是否有效），需要用证书认证机构的公钥来验证,而证书认证机构的公钥存在于对这份证书进行签名的上一级用户的数字证书内,上一级证书又要验明真伪。
  - 解决：根证书是一份特殊的证书，它的签发者是它本身，下载安装根证书就表明对该根证书及其所签发的证书都表示信任，而在技术上则是建立起一个验证证书信息的链条，证书的验证追溯至根证书即结束
4 证书管理
- 任何机构或者个人都可以申请数字证书，并使用数字证书对网络通信保驾护航。要获得数字证书，首先需要使用数字证书管理工，如keytool、OpenSSL等，然后构建CSR（Certificate Signing Request，数字证书签发申请），提交给数字证书认证机构进行签名，最终形成数字证书。
5 证书的使用
- 获得证书以后，可以使用公钥对相关信息进行加密，而信息接收方则使用私钥进行解密。由于证书包含了公钥、摘要算法等信息，也能够使用它来进行数字签名的校验

3 摘要认证

1 为什么需要认证

HTTP协议进行通信的数据大都是未经加密的明文，包括请求参数、返回值、cookie、head等数据，因此，外界通过对通信的监听，便可轻而易举地根据请求和响应双方的格式，伪造请求与响应，修改和窃取各种信息
更为危险的事情是,攻击者可以通过对一些网络核心节点的控制，再加上一些特殊的手段，如端口映射、代理监听等，使其能够监听和拦截到大量用户的通信数据包，通过对数据包进行筛选和分析，可以得到通信所涵盖的用户的所有敏感信息，如电子邮件、聊天记录甚至是登录的用户名和密码

2 摘要认证的原理

普通的非敏感数据
- 更多关注其真实性和准确性
鉴于使用HTTPS性能上的成本以及需要额外申请CA证书，在这种情况下，一般采用对参数和响应进行摘要的方法，即能够满足需求
对每次请求和响应，按照一定的规则生成数字摘要
- 请求参数是无序的
  - 客户端与服务端双方需要约定好参数的排序方式,再将参数名称和值经过一定的策略组织起来
- 将参数名称和值经过一定的策略组织起来，加上一个密钥secret，也就是所谓的“盐”，然后通过约定的摘要算法生成数字摘要，传递给服务端

3 摘要认证的实现

客户端参数摘要生成
- 请求参数摘要的生成过程
服务端参数摘要校验
- 服务端参数摘要验证
服务端响应摘要生成
响应的摘要串生成过程
客户端响应摘要校验
- 客户端响应摘要的校验过程

4 签名认证

签名认证的原理
- 由于传递端和接收端都认为HTTP协议的请求参数是无序的，因此对于签名认证来说，客户端与服务端双方需要约定好参数的排序方式。请求的参数经过排序后，再将参数名称和值经过一定的策略组织起来，这时不再是加上secret，而是直接通过约定的摘要算法来生成数字摘要，并且使用客户端私钥对数字摘要进行加密，将加密的密文传递给服务端
签名认证的实现
客户端参数签名生成
- 客户端请求数字签名生成
服务端参数签名校验
- 服务端对客户端数字签名校验
服务端响应签名生成
- 服务端响应数字签名生成
客户端响应签名校验
- 客户端对响应签名的校验过程

5 HTTPS协议

HTTPS协议原理
- 摘要认证和签名认证虽然能够解决数据完整性和通信两端合法性问题，但是对于一些较为敏感的信息，如个人隐私数据、用户名密码等，这些信息如以明文的形式传递，一旦用户的通信被拦截，相关信息会有较大的泄露风险，因此，有必要采用更加严密的手段来保障信息的安全
- HTTPS的全称是Hypertext Transfer Protocol over Secure Socket Layer，即基于SSL的HTTP协议，简单地说就是HTTP的安全版
- 依托SSL协议，HTTPS协议能够确保整个通信过程都是经过加密的，密钥随机产生，并且能够通过数字证书验证通信双方的身份，以此来保障信息安全。其中证书中包含了证书所代表一端的公钥，以及一些其所具有基本信息，如机构名称、证书所作用域名、证书的数字签名等，通过数字签名能校验证书的真实性。通信的内容使用对称加密方式进行加密，通信两端约定好通信密码后，通过公钥对密码进行加密传输，只有该公钥对应的私钥，也就是通信的另一端能够解密获得通信密码，这样既保证了通信的安全，也使加密性能和时间成本可控
- HTTPS协议栈
- HTTPS既支持单向认证，也支持双向认证，所谓的单向认证即只校验服务端证书的有效性，而双向认证则表示既校验服务端证书的有效性，同时也需要校验客户端证书的有效性
  - 大部分情况下我们并不需要用到客户端证书，很多用户甚至没有客户端证书，但是在某些特定的环境下，如企业内部网络和涉及大额交易支付的场景下，也需要对用户的客户端证书进行校验，以保证通信的安全

6 OAuth协议

摘要认证、签名认证和HTTPS协议，能够保障客户端与服务端在双方相互信任情况下通信的安全
随着互联网的深入发展，一些互联网巨头逐渐积累了海量的用户和数据。对于平台级的软件厂商来说，用户需求多种多样，变化万千，以一己之力予以充分满足，难免疲于奔命，因此，将数据以接口的形式下放给众多的第三方开发者，便成了必然的趋势。第三方开发者经过二次开发，满足一小部分的用户的独特需求，即能够使自己获得利益，也能够让数据流动起来，在大平台周围形成一个良性的生态环境，最终达到用户、平台商、第三方开发者共赢
1 OAuth的介绍
- OAuth协议旨在为用户资源的授权访问提供一个安全、开放的标准。平台商通过OAuth协议，提示用户对第三方软件厂商（ISV）进行授权，使得第三方软件厂商能够使用平台商的部分数据，对用户提供服务
- 平台厂商通过OAuth协议对第三方应用授权
2 OAuth授权过程
- OAuth发展到目前为止，一共经历了OAuth1.0、OAuth1.0a、OAuth2.0等几个版本,其核心思想都是将资源做权限分级和隔离，ISV引导用户在平台端登录，完成授权。获得授权后ISV可以在一定时间段内访问用户的私有数据，用户可以完全把控这一过程，且授权可取消。这样第三方ISV能够利用平台商所拥有的一些数据来服务用户
- 要获得OAuth协议授权，首先需要第三方开发者向平台商申请应用ID，即appId，对自己的APP进行注册。一次OAuth授权涵盖了三个角色：普通用户（consumer）、第三方应用（ISV）、平台商（platform）
- OAuth协议授权数据访问过程
  - 1 用户先对ISV的应用进行访问，发起请求。
  - 2 ISV接收到用户请求后，再向平台商请求request token，并带上其申请的appId。
  - 3 平台将返回给第三方应用request token。
  - 4 ISV应用将用户引导到平台的授权页面，并带上自己的appId、request token和回调地址。
  - 5 用户在平台的页面上进行登录，并且完成授权（这样便不会将用户名密码赤裸裸地暴露给第三方）
  - 6 平台通过ISV提供的回调链接，返回给ISV应用access token。
  - 7 ISV应用通过access token取到用户授权的数据，进行加工后返回给用户，授权数据访问完成。

来源大型分布式网站架构设计与实践

3. 互联网安全架构

1. 常见的Web攻击手段

l.1 XSS(Cross Site Scripting)攻击

1.2 CSRF(cross site request forgery)攻击

1.3 SQL注入攻击

1.4 文件上传漏洞

1.5 DDos(Distributed Denial of Service)攻击

1.6 其他攻击手段

2. 常用的安全算法

2.1 数字摘要

2.2 对称加密算法

2.3 非对称加密算法

2.4 数字签名

常见签名算法

2.5 数字证书

3 摘要认证

1 为什么需要认证

2 摘要认证的原理

3 摘要认证的实现

4 签名认证

5 HTTPS协议

6 OAuth协议

猜你喜欢

热点阅读