5分钟教你如何设计一个安全web架构

Posted 2023-04-01 无名之辈之码谷娃

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了5分钟教你如何设计一个安全web架构相关的知识，希望对你有一定的参考价值。

今天就给大家聊聊web安全，web安全占比还是比较大的，基础的从一些html标签，到js 然后到接口，数据库，以及流量攻击，模拟请求。当然这也谈到了一个概念，全新的架构设计模式，前后端分离，让后台着重管理数据处理，处理吞吐量，而前台就着重响应数据，给客户带来良好的体验。这也说明web安全架构也是一个不可小觑的一个重要过程，当然真正做好一个web网站实际上也是比较麻烦滴。现在基本很多网站都还有许多问题，我不介意大家去攻击别人网站，毕竟这是违法的事，自己可以模拟测试，你要知道漏洞你首先要学会如何防御。

一，DDoS

第一个DDOS比较常见啦，也是最难防御的一个漏洞。目前还没有人敢说能彻底防御滴。除非你自己开发一套加密的网络协议，各种复杂算法。这样还有可能避免，毕竟程序都是有漏洞滴。

DDoS就是流量攻击。

由于DDoS攻击往往采取合法的数据请求技术，再加上傀儡机器，造成DDoS攻击成为最难防御的网络攻击之一。据美国最新的安全损失调查报告，DDoS攻击所造成的经济损失已经跃居第一。

传统的网络设备和周边安全技术，例如防火墙和IDSs(Intrusion Detection Systems)，速率限制，接入限制等均无法提供非常有效的针对DDoS攻击的保护，需要一个新的体系结构和技术来抵御复杂的DDoS拒绝服务攻击。 DDoS攻击主要是利用了internet协议和internet基本优点——无偏差地从任何的源头传送数据包到任意目的地。

如何基础防御：

1，对频繁请求的ip和接口进行限流，熔断处理，超过多少次必须输入图形验证码。进行验证处理，减轻服务器数据库处理压力。其实现在很多大公司都是把一下接口放在一个项目里面进行rpc远程调用处理。通过分布式缓存，分布式一致性问题，分布式事务来解决这些问题。

2，使用黑名单和白名单机制，防御攻击（OAuth2.0协议）这个推荐使用。这个黑名单白名单就是现在很多代理网站来给你处理网站的安全性，也算是给你防御网站吧。

3，选择高防数据中心：国内数据中心一般都会有防火墙防御，我们今天把防火墙情况分为两种（1）集群防御，单线机房防御一般在：10G-32G的集群防御，BGP多线机房一般为：10G以内集群防火墙。当然这个并不是说您服务器就可以承受这么大的攻击，一般单机防御在1G-2G左右，具体根据每个机房的政策而定。所以一般这种集群防御的机房都是不给客户承诺具体防御能力。（2）独立防御，独立防御都是出现在单线机房，或者是多线多ip机房，机房防御能力一般为：10G-200G不等，这种机房是实现的单机防御能力，随着数据中心的防御能力提高还有就是竞争压力比较大，高防的价格也在不断的创造新低。像独立高防服务器一般都出现在单线机房所以这种方式会出现一种情况，联通率差，所以现在国内很多运营商也在改善这种现状，比如说亿恩科技就推出了三线三ip的高防服务器。防御能力能够达到100G-200G，并且把互联互通性的问题也得以解决。

4、CDN内容分发：

通过CDN防御的方式：CDN技术的初衷是提高互联网用户对网站的访问速度，但是由于分布式多节点的特点，又能够对分布式拒绝攻击流量产生稀释的效果。所以目前CDN防御的方式不但能够起到防御的作用，而且用户的访问请求是到最近的缓存节点，所以也对加速起到了很好的作用。CDN防御的最重要的原理也是通过智能DNS的方式将来自不同位置的流量分配到对应的位置上的节点上，这样就让区域内的节点成为流量的接收中心，从而将流量稀释的效果，在流量被稀释到各个节点后，就可以在每个节点进行流量清洗。从而起到防御作用。

目前针对DDOS流量攻击的防护方法中CDN防御也分为自建CDN防御，这种情况防御能力较好，但是成本较高，需要部署多节点，租用各个节点服务器，如果应用较少的话，造成资源浪费。另外就是租用别人现成的CDN防御，可以极大的节省成本，并且防御能力很少非常好。

二，csrf模拟请求

Cross Site Request Forgery, 跨站域请求伪造是一种网络的攻击方式，它在 2007 年曾被列为互联网 20 大安全隐患之一,也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用也就是人们所知道的钓鱼网站。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。

也就是通俗一点来说就是，大量请求你的接口，通过抓包工具请求分析，伪造token访问你的接口，攻击服务器降低服务器数据库性能。

如何解决防御？

模拟请求这里还是要说到分布式，毕竟真的要用到分布式，缓存集群。解决限流，服务容错，熔断的问题。

后端防御：

1，MVCC方案

　多版本并发控制，该策略主要使用 update with condition（更新带条件来防止）来保证多次外部请求调用对系统的影响是一致的。在系统设计的过程中，合理的使用乐观锁，通过 version 或者 updateTime（timestamp）等其他条件，来做乐观锁的判断条件，这样保证更新操作即使在并发的情况下，也不会有太大的问题。例如

select * from tablename where condition=#condition# // 取出要跟新的对象，带有版本 versoin

update tableName set name=#name#,version=version+1 where version=#version#

在更新的过程中利用 version 来防止，其他操作对对象的并发更新，导致更新丢失。为了避免失败，通常需要一定的重试机制。

2.去重表

在插入数据的时候，插入去重表，利用数据库的唯一索引特性，保证唯一的逻辑。

3，悲观锁

select for update，整个执行过程中锁定该订单对应的记录。注意：这种在 DB 读大于写的情况下尽量少用。

4，Token机制,防止页面重复提交

把token放在redis 里面通过限流方式，每个token只能使用一次，网络延迟或者重试机制解决这个问题。

5，MQ消息中间件也可以解决这个问题，可以通过发布订阅的方式来消息通知处理。

6，nginx服务器对域名网关拦截处理，只能通过域名访问，不能获取到你的ip，所以的前台文件通过分离来实现。

7，分布式校验

在大型网站中，使用Session存储CSRF Token会带来很大的压力。访问单台服务器session是同一个。但是现在的大型网站中，我们的服务器通常不止一台，可能是几十台甚至几百台之多，甚至多个机房都可能在不同的省份，用户发起的HTTP请求通常要经过像Ngnix之类的负载均衡器之后，再路由到具体的服务器上，由于Session默认存储在单机服务器内存中，因此在分布式环境下同一个用户发送的多次HTTP请求可能会先后落到不同的服务器上，导致后面发起的HTTP请求无法拿到之前的HTTP请求存储在服务器中的Session数据，从而使得Session机制在分布式环境下失效，因此在分布式集群中CSRF Token需要存储在Redis之类的公共存储空间。

由于使用Session存储，读取和验证CSRF Token会引起比较大的复杂度和性能问题，目前很多网站采用Encrypted Token Pattern方式。这种方法的Token是一个计算出来的结果，而非随机生成的字符串。这样在校验时无需再去读取存储的Token，只用再次计算一次即可。

这种Token的值通常是使用UserID、时间戳和随机数，通过加密的方法生成。这样既可以保证分布式服务的Token一致，又能保证Token不容易被破解。

在token解密成功之后，服务器可以访问解析值，Token中包含的UserID和时间戳将会被拿来被验证有效性，将UserID与当前登录的UserID进行比较，并将时间戳与当前时间进行比较。

前台防御：

1.CSRF监控

对于一个比较复杂的网站系统，某些项目、页面、接口漏掉了CSRF防护措施是很可能的。

一旦发生了CSRF攻击，我们如何及时的发现这些攻击呢？（这里其实nginx也可以处理）

CSRF攻击有着比较明显的特征：

跨域请求。
GET类型请求Header的MIME类型大概率为图片，而实际返回Header的MIME类型为Text、JSON、HTML。

2，通过对称非对称算法，前台网站访问先访问后台获取到应签，然后在把前台请求的参数拿到后台去检验。一般网络上面接口支付都是重定向啦。这样一般都比较麻烦。但是这样安全性能很高的，其实ssl证书比域名都贵滴。

3，用双重Cookie防御CSRF的

优点：

无需使用Session，适用面更广，易于实施。
Token储存于客户端中，不会给服务器带来压力。
相对于Token，实施成本更低，可以在前后端统一拦截校验，而不需要一个个接口和页面添加。

缺点：

Cookie中增加了额外的字段。
如果有其他漏洞（例如XSS），攻击者可以注入Cookie，那么该防御方式失效。
难以做到子域名的隔离。
为了确保Cookie传输安全，采用这种防御方式的最好确保用整站HTTPS的方式，如果还没切HTTPS的使用这种方式也会有风险。

三，sql注入?

SQL注入：利用现有应用程序，将（恶意）的SQL命令注入到后台数据库执行一些恶意的操作。造成SQL注入的原因是因为程序没有有效过滤用户的输入，使攻击者成功的向服务器提交恶意的SQL查询代码，程序在接收后错误的将攻击者的输入作为查询语句的一部分执行，导致原始的查询逻辑被改变，额外的执行了攻击者精心构造的恶意代码

SQL注入（SQLi）是一种注入攻击，，可以执行恶意SQL语句。它通过将任意SQL代码插入数据库查询，使攻击者能够完全控制Web应用程序后面的数据库服务器。攻击者可以使用SQL注入漏洞绕过应用程序安全措施；可以绕过网页或Web应用程序的身份验证和授权，并检索整个SQL数据库的内容；还可以使用SQL注入来添加，修改和删除数据库中的记录。

SQL注入漏洞可能会影响使用SQL数据库（如mysql，Oracle，SQL Server或其他）的任何网站或Web应用程序。犯罪分子可能会利用它来未经授权访问用户的敏感数据：客户信息，个人数据，商业机密，知识产权等。SQL注入攻击是最古老，最流行，最危险的Web应用程序漏洞之一。

SQL注入攻击的类型

SQL注入攻击可以通过多种方式执行。在选择特定攻击方法之前，攻击者可能会观察系统的行为。

带内注入

这是典型的攻击，攻击者可以通过相同的通信通道发起攻击并获得结果。这是通过两种带内技术完成的：

●　基于错误的SQL注入：从显示的错误消息中获取有关数据库的信息

●　基于联合的SQL注入：依赖于攻击者能够将UNION ALL被盗信息的结果与合法结果连接起来。

这两种技术都依赖于攻击者修改应用程序发送的SQL，以及浏览器中显示的错误和返回的信息。如果应用程序开发人员或数据库开发人员无法正确地参数化他们在查询中使用的值，那么它会成功。两者都是试错法，可以检测到错误。

盲注入

也称为推理SQL注入，盲注入攻击不会直接从目标数据库中显示数据；相反，攻击者会仔细检查行为中的间接线索。HTTP响应中的详细信息，某些用户输入的空白网页以及数据库响应某些用户输入需要多长时间，这些都可以是线索，具体取决于攻击者的目标。他们还可以指向攻击者尝试的另一个SQLi攻击途径。

带外注入

这种攻击有点复杂，当攻击者无法在单个直接查询 - 响应攻击中实现其目标时，攻击者可能会使用此攻击。通常，攻击者会制作SQL语句，这些语句在呈现给数据库时会触发数据库系统创建与攻击者控制的外部服务器的连接。以这种方式，攻击者可以收集数据或可能控制数据库的行为。

二阶注入就是一种带外注入攻击。在这种情况下，攻击者将提供SQL注入，该注入将由数据库系统的单独行为存储和执行。当二级系统行为发生时（它可能类似于基于时间的作业或由其他典型管理员或用户使用数据库触发的某些事情）并且执行攻击者的SQL注入，那就是当“伸出”到系统时攻击者控制发生了。

如何防御？

1.规范sql 写的方式不要写拼接sql,、最好使用预编译方式，在mybatis编写sql语句的时候，最好使用?传参数方式，不要使用#传参数，因为#传参数方式，可能会受到sql语句攻击。

#: 解析为一个 JDBC 预编译语句（prepared statement）的参数标记符，一个 # 被解析为一个参数占位符,可以防止SQL注入问题。

$: 仅仅为一个纯碎的 string 替换，在动态 SQL 解析阶段将会进行变量替换。

2.限制数据库权限和特权

将数据库用户的功能设置为最低要求；这将限制攻击者在设法获取访问权限时可以执行的操作。

避免直接向用户显示数据库错误

攻击者可以使用这些错误消息来获取有关数据库的信息。

对访问数据库的Web应用程序使用Web应用程序防火墙（WAF）

这为面向Web的应用程序提供了保护，它可以帮助识别SQL注入尝试；根据设置，它还可以帮助防止SQL注入尝试到达应用程序（以及数据库）。

3.定期测试与数据库交互的Web应用程序

这样做可以帮助捕获可能允许SQL注入的新错误或回归。

将数据库更新为最新的可用修补程序

这可以防止攻击者利用旧版本中存在的已知弱点/错误。

4.后台日志分析sql 可以使用AOP拦截写入sql性能

四，防盗链？

防盗链就是A网站有一张图片，B网站要引用过来使用到自己网站，引用图片和样式，js等等。

如何防御？

1，写一个过滤器判断http请求头Referer域中的记录来源的值，如果和当前访问的域名不一致的情况下，说明该图片可能被其他服务器盗用。

2，通过动静分离或者前后端分离。通过nginx配置。

3，可以通过shiro权限判断链接重定向。

五，什么是XSS?

Xss就是javascript 脚本攻击，就是在表单提交的时候提交一个小脚本，因为浏览器默认是支持脚本的，所以写个小脚本不做处理的话问题就很大。不处理网页直接挂掉。

如何防御？

1，通过后台编写一个过滤器拦截所有getParameter参数重写httpservletwrapp方法。

2，通过工具类将参数特殊字符转换成html源代码保存。

3，通过js检验

过滤用户输入的检查用户输入的内容中是否有非法内容。如<>（尖括号）、”（引号）、 ‘（单引号）、%（百分比符号）、;（分号）、()（括号）、&（& 符号）、+（加号）等。、严格控制输出

六，文件上传漏洞

什么是文件上传漏洞？

上传漏洞这个顾名思义，就是攻击者通过上传木马文件，直接得到WEBSHELL，危害等级超级高，现在的入侵中上传漏洞也是常见的漏洞。导致该漏洞的原因在于代码作者没有对访客提交的数据进行检验或者过滤不严，可以直接提交修改过的数据绕过扩展名的检验。

大家经常在网上下载文件什么东西，比如一个软件，默认几十M但是下下来为啥只有几百Kb很多网站都是钓鱼网站，你下载下来的文件是后缀为.exe文件，这是系统运行文件，文件下载也有这个问题，所以网上很多不靠谱滴，不要乱下载文件。

如何解决防御？

1 对文件格式限制，只允许某些格式上传

2 对文件格式进行校验，前端跟服务器都要进行校验（前端校验扩展名，服务器校验扩展名、Content_Type等）

3 将上传目录防止到项目工程目录之外，当做静态资源文件路径，并且对文件的权限进行设定，禁止文件下的执行权限。

4 通过文件流解析判断文件类型。

七忘记密码漏洞？

我在这里分析一个常见的qq漏洞，现在很多都还有人家盗用别人密码，然后通过qq发送消息，找你借钱或者转账到某个地方，黑客就是通过抓包分析暴力破解密码（写一个程序破解验证码，如果是4位纯数字可想而知），然后盗取你的短信验证码登录，如果发生了这样的情况，如果是qq的话你就一直发短信验证码，联系客户还得一段时间。因为大家都知道qq验证码都是4位所以别人很好破解，我这里说的都是真实案例，因为我以前也被别人这样操作过，但是我就一直频繁发短信验证码后面就找回来啦。

如何防御：

1，忘记密码验证码最好在6-8位最好是加字符，字母组合。

2 一旦频繁调用接口验证时，应该使用图形验证码拦截，防止机器模拟。

3，使用黑名单和白名单机制，防御攻击（OAuth2.0协议）。

结语：

如何设计一个安全的web架构，要设计一个高性能的web安全防御，可以自己设计，也可以找第三方代理给你安全保障也可以。但是说实话完全设计好一个web安全程序还是比较有深度滴。以上就是我给大家分享的常见安全漏洞，处理掉这些漏洞，你的网站基本没问题啦。

如何设计 Web App 应用架构？「两分钟了解 IOING」

IOING 在做些什么？

IOING 在你的代码和浏览器之间架设了一个中间解释层，该解释层提供了一套新的语法来填补浏览器所不具备的能力。

SPA 开发痛点

开发一个 SPA 应用的痛点是不同模块页面的状态保存，当从一个页面跳转到另一个页面的时候窗口的所有状态都将被清空重载，历史页面与当前页面将不产生任何联系，这个过程是一个拆毁重建的过程，如果你要回到历史同样只能再次拆毁重建，并且在这个过程中不可避免的出现加载期的窗口白屏，显然这样的丑陋效果不符合一个高贵 App 的设定，但正因这种方式前后页面不共存的简单特性也使得开发逻辑变得简单，开发者只需考虑单个页面的逻辑即可，而每一次新页面的加载都能将之前页面进行完全释放，完全不需要担心高耦合和内存无法完全释放的问题，这也算是传统技术的优点，虽然简单粗暴，但是它很管用。那到底有没有两全其美的办法呢？

传统模式带来的挑战

和 SPA 应用不同的是多页面应用往往相对要变得简单，页面与页面之间不需要有复杂的数据交换，也无需保存页面历史状态，因此使用传统技术最适合不过了。

而 SPA 应用则要协调页面间的关系，它的每一个模块都可能是联动的，而且需要保持窗口的数据状态，因而催生了另一个技术的流行，即通过使用 Ajax 和模版将新模块内容载入到当前页面，但这也导致新载入模块的脚本和 DOM 树内容在主文档下不断堆积，且在不需要时也无法将其很好移除和释放（比如 setTimeout 等僵尸事件）。另一种情况是一旦其中一个模块发生错误将很有可能导致整个 SPA 应用崩溃。

除了高耦合问题外，Ajax 每次载入大量的 DOM 结构到主 DOM Tree 下时都将可能会导致这个庞大的 DOM Tree 进行 reflow(回流) 和 repaint(重绘)，从而影响整体运行效率

实现方案分析

基于上述分析，我们要得到一个稳定的 SPA 应用时必须改造浏览器使其支持以下特性：

为保证应用松耦合，浏览器必须具备能够使新加载的模块与已加载模块不产生相互干扰的能力。
为使浏览器载入大量模块时不会造成内存占用过高，浏览器应能使被移除后的模块能被完全释放。
浏览器应使模块运行在独立空间中，以保证模块自身错误时不至于导致整个应用停止工作。

只有具备了这些特性时才能保证一个大型 WEB 应用的稳定运行，那么对于上述问题 IOING 是怎么处理的呢？

首先为了保证模块的代码错误不至于影响整个应用的运行，我们需要保证除引擎外的所有不可控脚本都不能运行在主 window 下，而模块脚本自需要运行在单独的沙盒中。

什么是沙盒模块？

沙盒（Sandbox）简单来讲就是: <iframe src="_blank" sandbox="..."></iframe>
无需解释大家也就都懂了，但是很多人在看到 iframe 时就开始各种担心起来，联想起各种文章对 iframe 的负面描述。这里需要解释一下，iframe 直接作为嵌入网页使用时确实会占用当前页面连接池，但其在引擎中其主要目的是作为沙盒使用而并不是为了嵌入网页使用的，当引擎将编译好内容时会先主动创建一个空 iframe，然后直接将编译内容直接丢入其中，注意 iframe 的 src="_blank"，这是一个空页面，该情况下 iframe 并不会共享主窗口连接池。

我们设想一下这样一个场景：你在浏览器打开多个窗口分别载入不同的模块页面，然后在你需要打开其他页面时能通过自定义动画使浏览器窗口进行动画过渡将页面展示，当你返回时也能通过反向动画再将之前窗口内容过渡回来，如果浏览器支持这些或许 webApp 看起来将更酷，但现实是浏览器并没有这样的操作??♂?。

而这个设想可以通过沙盒来实现，在沙盒中的页面就像新开一个浏览器窗口那样，能够很好的隔离模块的 DOM 元素和变量，也能保存页面状态，并能通过动画控制其转场。

沙盒虽然很稳妥，但其过于独立，这导致模块内元素不能突破沙盒限制显示在模块外区域，比如说一些复合型模块（即嵌入主模块中的模块，沙盒一般适用与独立的全屏模块），当你有这个需求时沙盒特性则不能满足你，此时你应该支持另一种模块运行方式：shadowbox 应运而生。

shadowbox

使用 shadowbox 配置的模块，其模块内容将以一颗新 DOM Tree 插入到主 DOM Tree 中（即 shadowdom 方式），这颗新 DOM Tree 中的 CSS样式和元素id 将不会和外部元素耦合，而此时模块的 js 文件则依旧在其沙盒中运行。（若运行浏览器不支持该特性时应自动降级处理）