关于开发人员需要注意的网络攻防知识梳理

一、网站常见的安全问题

前端页面在访问服务器获取资源的时候，往往可以携带一些服务器需要的信息，甚至包含一些较为重要的机密信息，因此，在一个完整的网页服务中，开发者需要在各个阶段确保数据甚至是服务的安全。

1. 跨站脚本攻击（XSS）

XSS攻击允许攻击者将恶意脚本注入到用户浏览的网页中。这些脚本可以在用户的浏览器上执行，从而窃取用户的敏感信息（如Cookie、会话令牌等），或者进行其他恶意操作（如重定向用户到恶意网站）

例如，攻击者在表单提交页面提交一份js代码，而服务端未经过解析，这段js代码会将用户的信息发送给攻击者的服务器，导致用户信息泄露。

XSS攻击可以通过对参数的验证去规避，但以我个人的一个观点，对参数的验证去规避，往往只能保证当前已经为人所知的攻击，没法从源头杜绝危险。

2. cookie、localstorage信息泄露

Web应用的敏感数据（如用户登录状态、个人信息等）往往会存储在cookie或者localstorage这样的缓存之中，当访问用户个人数据时，需要从缓存中拿到token或其他授权信息，去访问服务器获取信息，如果这些个人数据或授权信息遭到泄露，同时服务器未限制访问来源，那么攻击者可以肆无忌惮地窃取、窥探用户的个人信息。一些涉及金钱的业务甚至会有更严重的后果。

3. struct2漏洞攻击（网页木马上传&文件包含）

struct2漏洞是利用框架自带的上传功能，开发者直接套用，而没对其进行更多限制和优化，导致的漏洞，具体攻击方式如下：
攻击者首先利用该文件上传功能，上传一些可执行文件到服务器，然后再发送请求访问该可执行文件去执行，导致的所有机密信息都可以用该脚本进行窃取。
解决方案：该安全问题是服务端导致的，直接对服务器所有资源造成威胁的，与请求发送地址无关，服务需要做好文件类型的限制（应急措施），然后升级struct2补丁包修复漏洞。

4.CSRF（跨站请求伪造）

跨站请求伪造是攻击者对用户行为进行引导，致使用户触发攻击者写好的请求代码，从而发送伪造用户身份的请求，完成的攻击手段，具体过程如下：
比如用户打开银行网页，登录后，在执行转账前，攻击网页弹出一个伪造的提示，用户一旦点击该提示信息试图了解详情，则会执行攻击者为该伪造提示设置的攻击代码，代码可能是转正等敏感操作，而此时由于请求的服务器为银行网页，浏览器会将用户身份信息连同请求一起发送，服务器验证通过后就会执行攻击者的请求。
解决方案：每次访问都采用一个随机数，确保每个访问都是预期之内的访问

5.DDos（CC攻击）

通过发送大量合法请求，使目标服务器资源耗尽，导致拒绝服务。CC攻击是一种DDoS（分布式拒绝服务）攻击。
解决方案：使用DDos防护服务/防火墙，限流策略保证保护服务。

二、问题归纳和思考

我们以请求发送，和文件上传两条链路为基础，用画图的方式列一下这些漏洞发生的过程和位置：

图中可以看到，这五个攻击类型之中

只能由服务端控制的分别是：

• DDos（CC攻击）
• struct2漏洞攻击（网页木马上传&文件包含）

只能由浏览器/前端控制的是：

• 窃取cookie、localstorage

需要服务端与浏览器/前端共同控制的是：

• CSRF（跨站请求伪造）
• 跨站脚本攻击（XSS）

三、服务器端的防御措施

1、防止DDos攻击

1）DDos防护服务

可以购买成熟的DDos防护服务来保证服务器的安全运行；

2）使用防火墙和过滤器设置

配置和优化防火墙规则可以过滤掉恶意流量和异常请求，阻止DDoS攻击的影响。根据特定的网络流量模式，管理员可以设置规则来限制特定IP地址或协议的访问，以减少攻击的影响（详细的配置规则可以看下防火墙配置防护DDos攻击）。

3）使用反向代理服务器

使用反向代理服务器，在请求发到服务之前，对请求进行过滤，比如按照用户进行过滤，或者按照ip地址进行访问限制等等。

4）使用限流工具

使用限流工具并不是防护DDos攻击的最佳手段，但他可以保证服务器始终能够提供正常服务，是限制DDos的最后一道防线，但是也会影响正常用户的访问

总结：

防止DDos可以利用防火墙、过滤器、反向代理服务器去拒绝一些频次过高的访问，以削减攻击者的攻击频次保证攻击请求的比例始终处于可控范围，同时在服务提供端可以采用限流策略，作为最后一道防线，保障整个服务不会发生雪崩、崩溃等；

2、防止struct2漏洞攻击（网页木马上传&文件包含）

1）格式验证

对上传文件等功能进行文件格式验证，保证上传的文件中只包含安全（非系统操作类或可执行类）文件；同时对外部访问服务器资源的文件格式做限制，防止通过其他漏洞访问服务器的机密文件，或执行服务器的可执行文件等；

2）存储服务器分离

将文件存储封装到一个服务器中，文件服务器只负责文件存取，这也是分布式系统中最常用的文件存储方式。

3）更新struct2补丁

使用struct2框架导致的漏洞，可以通过升级补丁解决问题。

四、浏览器端的防御措施

1、浏览器同源策略

1）浏览器同源策略简介

同源策略是浏览器的一种安全策略，它要求两个页面（或资源）具有相同的协议（如HTTP、HTTPS）、域名（或IP地址）和端口号，才能相互访问彼此的资源和进行通信。这是为了防止恶意网站读取另一个网站的数据，从而保护用户的隐私和安全。而同源策略所规定的能相互访问的范围称为域，但是某些特殊请求确实要去到这个域之外的地址获取资源，因此有了跨域的概念

2）CORS机制

CORS是一种官方的跨域解决方案，它允许服务器通过特定的HTTP头部来显式地允许某些跨域请求。这些HTTP头部信息被包含在服务器的响应中，告诉浏览器该请求是允许跨域的。但是，CORS机制并不是绕过同源策略，而是在同源策略的基础上提供了一种额外的、可配置的跨域访问控制机制。

3）同源验证流程

• 第一步-验证同源：
  当浏览器尝试发起一个跨域请求时，它首先会检查请求的URL是否与当前页面的URL同源。如果同源则直接允许访问，否则执行下一步；
• 第二步-预检阶段：
  当不同源时（特别是那些“非简单请求”，如使用了自定义HTTP头部或HTTP方法的请求）时，它会自动先发送一个OPTIONS请求到目标服务器，询问服务器是否允许该跨域请求。OPTIONS请求中包含了Origin头部，用于标识请求的来源域。
• 第三步-服务器验证是否允许跨域：
  服务器在收到OPTIONS请求后，会检查请求的Origin头部，并决定是否允许该跨域请求。如果允许，服务器会在响应中添加CORS相关的头部信息，如Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers等。
• 第四步-浏览器确认是否允许跨域：
  浏览器在收到服务器的响应后，会检查CORS头部信息。如果响应中包含了允许跨域的头部信息，并且这些信息与请求相匹配，那么浏览器就会放行该请求，允许它继续执行。如果响应中没有包含允许跨域的头部信息，或者头部信息与请求不匹配，那么浏览器就会阻止该请求，并在控制台中报错。

4）同源策略防御CSRF攻击

由于CSRF攻击的其中一种攻击手段是通过引导用户点击网站，从而向被攻击服务器发送带有用户身份认证信息的请求，从而达到攻击的目的，在同源策略下，攻击者页面和被攻击者服务器不属于同一个域中，因此浏览器会禁止该跨域请求发送，而被攻击服务器不可能设置允许攻击者访问的配置，所以基本杜绝了CSRF的跨站攻击。
（但同源策略和CORS机制始终是浏览器控制的，如果浏览器被插件挟持，或者出现了漏洞，攻击者依然可以通过伪造成同源网站绕过同源策略检查和CORS检查，从而达到攻击的目的，因此还需要结合其他手段完成）

5）同源策略防御cookie、localstorage窃取

同源策略使得不同网站之间相互隔离，若A网站想要获取B网站中的cookie与localstorage数据时，浏览器会根据同源策略禁止其获取。

其他：

• 同源策略无法解决XSS攻击
  XSS攻击是注入脚本，运行脚本的方式进行的，虽然对于一些向第三方发送敏感数据的脚本，同源策略会限制，但是因为有了CORS机制，第三方网站依然可以通过配置CORS允许跨域访问来接受这些敏感信息；

2、CSP内容安全策略

1）CSP（Content Security Policy）简介

通过让开发者对自己WEB应用声明一个外部资源加载的白名单,使得客户端在运行WEB应用时对外部资源的加载做出筛选和识别,只加载被允许的网站资源.对于不被允许的网站资源不予加载和执行.同时,还可以将WEB应用中出现的不被允许的资源链接和详情报告给我们指定的网址.如此,大大增强了WEB应用的安全性.使得攻击者即使发现了漏洞,也没法注入脚本,除非还控制了一台列入了白名单的服务器.

2）CSP防御XSS攻击

XSS攻击是通过注入脚本，执行脚本来达到攻击的目的的，因此同源策略无法限制，XSS脚本有两种攻击方式：
一种是利用CORS机制，向第三方发送敏感数据，这种情况如果网页配置了CSP白名单列表，那么第三方网站就会因为没有处于白名单之内，而被限制访问，从而达到防御该种类的XSS攻击的目的；
一种是伪造请求向服务器发送非法请求，这种可以则需要通过其他手段来防御（敏感操作校验，随机码）

3）CSP防御CSRF攻击

CSRF攻击是通过植入非法请求诱导用户触发而达成的，其中一个攻击方法就是通过一些手段在原网页植入伪造的链接，而CSP可以有效防止攻击者对原网页的篡改，保证原网页的完整性，以此可以防住一些以此为突破口的CSRF攻击。

3、cookie中的httpOnly、sameSite属性

• httpOnly是给浏览器做的标识，意思是cookie的信息除了发送http请求的时候自动发送之外，其他情况下都无法访问该cookie，这样可以有效的保护cookie信息不被窃取。
• SameSite属性主要用于控制跨站点请求中是否发送cookie，旨在增强Web的安全性，特别是减少跨站请求伪造（CSRF）攻击的风险。这个属性是在近年来被引入的，以应对日益增长的网络安全威胁。
  SamSite有以下三个属性：
  • Strict：只会在当前网页的域名完全匹配的情况下发送cookie
  • Lax：浏览器会在顶级导航（如用户点击链接跳转）时发送cookie，但在跨域的GET请求（如通过<img>、<script>等标签发起的请求）中不会发送.
  • None：浏览器会在所有请求中发送cookie

五、其他安全措施

1、Https的作用

Https通过SSL加密层对数据传输进行加密，并将秘钥做成证书放在CA上，使得每个会话会有一个独立的对称加密秘钥（详细看Https安全传输协议），当请求被攻击者或者中间服务器拦截的时候，攻击者没有秘钥也无法读懂请求的内容，由此保证了数据传输过程中，数据的安全性。

2、其他加密

https给其他传输协议提供了一个安全传输的样例，在其他传输协议中，也可以自定义加密方式跟秘钥来保证数据传输过程的安全，即收发数据双方约定了某种加解密方式，在收到/发送数据的时候进行解密加密，从而保证数据的安全。其底层都是利用网络模型中编解码器，在其中加入加解密逻辑实现，像java的springboot可以通过实现拦截器去对数据进行加工，其底层是netty框架的编解码器实现。

六、总结

1）解决CSRF（跨站请求伪造）攻击

• 浏览器同源策略会限制csrf利用弹出界面等方式发出的攻击，需要跨域的情况下要合理配置好CORS配置；
• 设置cookie中的samesite为lax或者strict，以限制浏览器自动发送cookie，防止攻击页面伪造请求的攻击；
• 设置好CSP白名单，防止因注入等方式造成的请求外部资源进而发出csrf攻击的情况；
• 使用csrf令牌，对请求访问进行控制，防止伪造请求；

2）解决XSS（跨站脚本攻击）

• 服务端对所有写接口做好参数校验，并对所有读接口做好特殊字符转换，防止页面出现嵌入脚本的情况；
• 维护好CSP白名单，限制注入脚本非法发送敏感数据的情况
• 解决好可能因注入而导致的CSRF攻击的情况（如上）；

3）解决cookie、localstorage窃取

• 浏览器同源策略会防止外部网站对cookie、localstorage的访问；
• 设置cookie中httpOnly，并设置sameSite为lax或strict，保证cookie的安全；
• 维护好CSP白名单，保证即使绕过同源策略，恶意脚本也无法向第三方发送cookie、localstorage中的敏感数据。