小议怎么保证系统线上安全

                                小议怎么保证线上安全

 

1.缘起

最近面试XXX岗位中间遇到的问题，你是如何保证线上架构体系安全的？

初听 有点懵逼~ 粗略考虑了下，只从高可用方面浅谈了几种方式；细细思量后觉得回答这个问题

只从高可用来说还是远远不够的。

下面从基础设施安全；应用系统安全；数据安全；防重以及过载保护等几个方面来简议下。

 

2. 细说怎么保证线上安全

2.1 系统基础设施安全：

基础设施，也就是 应用服务器的安全；

安装杀毒软件，开启防火墙，使用攻击检测系统-设置白名单黑名单等方式；

 

2.2 应用系统安全：

1. sql注入：

防止sql 注入 最基本的方法是使用预编译语句，PreparedStatement进行sql操作；

主流关系型数据库中间件 mybatis 在参数传递时拼接sql 可以用 # 取参数，他会把参数

统一当做参数值的字符串。而 $ 则不会当做字符串处理；

 

2.CSRF攻击：

CSRF ： Cross-site request forgery 跨站点请求伪造；

通过其他web站点的网页端植入伪造的URL，然后借助浏览者的cookie中合法用户权

限，在当前合法用户不知情的情况下发送的伪造请求；因为通过cookie中的用户权限值

是合法的所以服务器识别不到该请求的非法性；-- 同一个浏览器的内打开的新窗口

cookie是共享的。

 

CSRF攻击实例：

以银行转账为例，用户在浏览器输入了银行网址登陆。登陆信息保存在cookie中，

在操作中途或结束后，又进行其他网页的浏览，那么在黑客维度看来，他可以知道

银行转账的post请求的URL只要将转账获益对象修改为自己，然后将这个请求的

URL 放在自己的网站上，然后刚才的用户刚好浏览到这个网站的网址，那么 他就

可以通过获取用户的cookie信息 发送这个事先做好的URL请求。由于该请求是 获

取的用户浏览器的COOKIE 信息 合法的登录的有权限的用户 服务器是识别不出来

的。所以在用户毫无知情的情况下钱就没了。而银行方面查看 请求来源也是用户的

电脑，权限验证也是通过的合法用户。钱不翼而飞。。。

 

CSRF攻击的对象是什么：

了解了CSRF攻击的本质了 下面聊下CSRF攻击的对象是什么吧。只有知道他攻击

的对象是什么才能有针对性的去做一些保护措施。

 

从攻击实例中可以看出，黑客通过CSRF 攻击的受害者有这样几个属性：

他们在操作银行网站中途又去看了别的网站致使黑客可以再伪造的网页中植

入伪造的URL请求代码，通过骗取受害者的Cookie来获取服务器的信任，而不

是直接获取用户的cookie。用户的cookie 黑客是拿不到也看不到的内容。对于

服务器返回的内容结果，由于浏览器有同源的限制，所以黑客是获取不到返回

数据源的。

综上可以推导出：

1. CSRF攻击的主要是会对服务器产生修改变更的请求；

2. get方式获取的请求URL对于黑客来说并不会被改变，被伪造，因为伪

造了也没意义；

 

CSRF 攻击如何防护：

了解了 攻击的对象了 那么我们就可以有针对性的进行CSRF防护了。

方案：

1. 在http请求头中会有一个 Referer 字段通过判定这个字段的域名是否是网站

域名来甄别服务请求；

正常情况下他记录了http请求的来源地址；既：银行服务器域名地址，比如

bank.excemple.cn，当请求过来时我们获取http头中的 referer 字段的值看是

否包含 服务器网站的域名地址即可进行甄别；如果是CSRF攻击的话 域名将会

是 黑客自己构建的网站的域名地址，而非银行网站域名地址；

 

 

2. 通过添加token方式将用户信息放入其中每次带着token进行操作后台验证

token；

 

黑客骗取用户cookie 来发送请求能成功是因为cookie是浏览器公用的内存空

间；那么我们用token 来存储用户登录信息后 黑客就拿不到用户的合法身份验

证信息--token了。

 

3. 在http头信息中自定义字段来存服务器信息传递给服务器进行身份验证；

方式类似 2 中描述的token 原理；

 

 

 

3. XSS 跨站脚本攻击：

cross site Scripting ： 跨越站点的脚本攻击，简称 xss 与 css样式表做区分。

3.1 什么是 xss 攻击？

就是在用户浏览器中 植入自己的java script脚本，获取用户信息如cookie等。

 

3.2 xss 攻击分类：

反射性xss攻击：

也成为非持久化方式攻击，是指恶意的脚本代码跟着请求发送到服务器，然后

服务器下发请求结果跟着一起带回。从而改变展示或增加非用户希望的消息；

攻击方式，是通过IM或邮件等方式发送攻击URL让用户点击来达到攻击的；

 

持久化xss攻击：

持久化xss攻击是将攻击的恶意脚本内容持久化服务器端的，比如帖子论坛中

回复留言等文本内容 被持久化到DB 当再次访问被植入恶意脚本的请求后就会

下发带有恶意脚本的内容从而达到 攻击目的；

攻击方式， 通过文本内容留言，或者bbs 博客等文本内嵌入恶意脚本上报服务

器后被服务器端持久化；

 

DOM xss 攻击：

此种攻击方式是 脱离服务器端的，直接会将恶意脚本内容嵌入到浏览器端；

 

3.3导致xss攻击的原因：

主要是对用户输入内容参数，包括URL参数和post请求参数没有进行过滤，导致恶

意代码混淆在正常请求参数中提交到了服务器，或者被服务器持久化了。当再次请

求相关地址时恶意代码会跟着请求结果一起下发给用户，那么在加载时就会 对用户

的返回结果产生恶意影响；

 

3.4xss攻击的规避：

总的实现思路就是 对用户输入的请求参数（URL参数以及post方式提交的参数）进

行 过滤，对用户请求的数据进行编码；

 

3.5xss攻击防御的实现手段：

在过滤器重对请求参数进行过滤，比如可以自己实现个 放xss攻击的过滤器对用户

提交参数进行过滤。 将容易导致xss攻击的 边角符号替换成全角符号；“<” 和 “>”

是脚本执行和各种html标签需要的，又比如javaScript 脚本是需要 <Script> 标签

的，我们可以针对这些做过滤替换；又比如将请求参数 进行加密 那么就会骗过过

滤器；绕过过滤器的过滤。

 

 

1.作为body文本输出，作为html标签的属性输出：

比如：<span>${username}</span>, <p><c:out value="${username}"></c:out></p>

<input type="text" value="${username}" />

此时的转义规则如下：

< 转成 &lt;

> 转成 &gt;

& 转成 &amp;

" 转成 &quot;

' 转成 &#39

2. javascript事件

<input type="button" οnclick='go_to_url("${myUrl}");' />

除了上面的那些转义之外，还要附加上下面的转义：

\ 转成 \\

/ 转成 \/

; 转成 ；(全角;)

3.URL属性

如果 <script>, <style>, <imt> 等标签的 src 和 href 属性值为动态内容，那么要确保这些url没有执行恶意连接。

确保：href 和 src 的值必须以 http://开头，白名单方式；不能有10进制和16进制编码字符。

4. HttpOnly 与 XSS防御

XSS 一般利用js脚步读取用户浏览器中的Cookie，而如果在服务器端对 Cookie 设置了HttpOnly 属性，那么js脚本就不能读取到cookie，但是浏览器还是能够正常使用cookie。(下面的内容转自：http://www.oschina.net/question/12_72706)

一般的Cookie都是从document对象中获得的，现在浏览器在设置 Cookie的时候一般都接受一个叫做HttpOnly的参数，跟domain等其他参数一样，一旦这个HttpOnly被设置，你在浏览器的 document对象中就看不到Cookie了，而浏览器在浏览的时候不受任何影响，因为Cookie会被放在浏览器头中发送出去(包括ajax的时 候)，应用程序也一般不会在js里操作这些敏感Cookie的，对于一些敏感的Cookie我们采用HttpOnly，对于一些需要在应用程序中用js操作的cookie我们就不予设置，这样就保障了Cookie信息的安全也保证了应用。

如果你正在使用的是兼容 Java EE 6.0 的容器，如 Tomcat 7，那么 Cookie 类已经有了 setHttpOnly 的方法来使用 HttpOnly 的 Cookie 属性了。

cookie.setHttpOnly(true);

设置完后生成的 Cookie 就会在最后多了一个 ;HttpOnly

 

XSS攻击访问方法：对输入(和URL参数)进行过滤，对输出进行编码；白名单

和黑名单结合；

 

 

4. 文件上传安全防御：

文件上传安全保障前，先了解下文件上传会产生那些安全漏洞：

上传了可执行的文件，然后远程执行这个文件导致的安全问题。

 

可以从以下几方面入手进行防护：

1. 上传目录设置为不可执行目录；

2. 上传文件时，对上传者进行身份验证，加权；

3. 上传时对文件后缀进行校验；

4. 上传后对文件名称进行随机修改；

5. 上传时添加白名单；

6. 上传的文件名中包含有 %00 类似截断符 进行过滤或禁止；

7. 对Http请求头中的 content- type 类型检查以及文件大小检查；

8. 同一个IP的上传次数限制，防止恶意上传文件撑爆图片服务器；

 

2.3 数据保密安全：

1. 数据存储安全 -- 保证数据容灾，冗余备份：

数据保存在可靠的服务器上，定期备份；又比如 mysql 的 HA ；多主 多从；

 

2. 保存安全--保证用户重要数据不被泄漏：

对信息安全要求等级高的数据进行 加密保存；

用户敏感信息 脱敏存储；

 

3. 传输安全--防止数据被窃取和篡改：

对用户敏感数据传输时 进行加密解密-- 对称加密解密 和 非对称性加密解密；

 

对非重要敏感数据进行 签名验证，防止篡改；

 

 

 

2.4 应用服务框架架构层级：比如Springcloud

有过载保护 hytrix 。

对用户请求做去重处理；

保证DB入库操作 幂等；