第十一周总结
1. 安全架构
信息安全一直都是互联网长期存在的问题,信息安全事故也一直在发生,比如:早期的CSDN密码泄露,安全问题可能平时不太引人注意,但是一旦发生都会带来重大的损失,因此我们在架构与开发的时候要时刻注意信息安全的问题。
owasp top 10 (开放式Web应用程序安全项目最常见的10个安全问题 )
https://owasp.org/www-project-top-ten/
1.1 XSS
跨站脚本攻击(XSS),是最普遍的Web应用安全漏洞。这类漏洞能够使得攻击者嵌入恶意脚本代码到正常用户会访问到的页面中,当正常用户访问该页面时,则可导致嵌入的恶意脚本代码的执行,从而达到恶意攻击用户的目的。
防御手段:
对用户输入的数据进行过滤与消毒(某些html字符转义)
1.2 SQL 注入
SQL注入攻击是黑客对数据库进行攻击的常用手段之一。部分程序员在编写代码的时候,没有对用户输入数据的合法性进行判断,使应用程序存在安全隐患。用户可以提交一段数据库查询代码,根据程序返回的结果,获得某些他想得知的数据,这就是所谓的SQL Injection,即SQL注入。
防御手段:
参数消毒,通过正则匹配,过滤请求数据中可能注入的SQL;
不要使用SQL拼接,使用SQL预编译参数绑定
1.3 CSRF
跨站请求伪造(英语:Cross-site request forgery),也被称为 one-click attack 或者 session riding,通常缩写为 CSRF 或者 XSRF, 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨网站脚本(XSS)相比,XSS 利用的是用户对指定网站的信任,CSRF 利用的是网站对用户网页浏览器的信任。
防御手段:
表单token : 每次请求页面都会返回一个随机数token, 请求提交后检查token的值是否正确
验证码 : 在一些关键功能加上验证码
referer check : 利用http head 中的 referer 检查请求来源,但是有可能获取不到
1.4 其他漏洞
error code (错误回显),配置独立的出错页面
html 注释,code review,html发布前去掉注释
文件上传,设置上传文件白名单,禁止上传可执行程序,上传成功后修改文件名,使用专门存储手段
路径遍历,静态资源,动态资源 独立部署
1.5 一些常见的安全措施
WAF
Web应用防火墙 (Web Application Firewall) 是通过执行一系列针对HTTP/HTTPS的安全策略来专门为Web应用提供保护的一款产品。
可以自研,也可以使用开源的modsecurity,或者只用里面的规则。
网站安全漏洞扫描
一般安全团队都有自己开发的漏洞扫描工具,也有一些商业工具
信息加密技术及密钥安全管理
单项散列加密:主要有MD5、SHA、MAC、CRC等算法,一般用于用户密码的加密,为了防止通过彩虹表等反向查询,可以加盐
对称加密:用于系统内的加解密
非对称加密:公钥加密,私钥解密;或者私钥加密,公钥验签
密钥安全管理与加解密服务系统架构:
使用机器学习进行反垃圾与风控
传统的方案基本都是通过规则引擎来进行反垃圾与风控,但是业务逻辑会比较复杂而且不够灵活,规则也有一定的滞后性。
随着大数据和AI技术的成熟,可以通过贝叶斯、SVM、机器学习等AI技术,使用大量的标注好的数据进行模型训练,在通过模型进行相关行为的识别。
2. 高可用系统架构
2.1 高可用系统的度量
网站年度可用性指标 = (1 - 网站不可用时间/年度总时间) * 100%
网站不可用时间(故障时间) = 故障修复时间点 - 故障发现(报告)时间点
一般互联网应用可用性是4个9
过分追求可用性,会需要大量的人力、财力的投入,因此还是需要看具体的业务场景,所允许的可用性范围。
2.2 引起故障的原因
参考作业中的总结:
https://xie.infoq.cn/article/d92007937ea55063367a9e3bd
2.3 高可用的方案
同上
2.4 高可用系统的运维
同上
3. 总结
系统的安全是一直是系统中非常重要的部分,尤其是在金融、银行、证券 等行业内。我的第一份工作就是企业网银的开发,当时团队进行了多次的安全培训,提交的代码会进行安全扫描,定期进行code review,线上会有独立的安全团队进行模拟攻击,发现系统漏洞。
当时的一些主要的安全措施:
JSP中不允许有html注释,只允许有Java注释
js中检查当前窗口是否是top window,防止被作为iframe嵌入到别的系统
用户在登录前的session,在登录完成后要禁用,并且重新创建一个新的,防止之前sessionid被泄露
所有的form提交使用struts2 token, 防止CSRF和重复提交
所有的form中不允许提交id ( 比如userid, company id 等),取而代之的是使用uuid,后台的有uuid与id的映射关系
日志中隐私信息(账号、密码、金额等)都需要做隐藏
使用SQL预编译传参,防止SQL注入攻击
使用Secure cookie,cookie中不放敏感信息
使用websphere对url进行加密
自定义filter对用户的输入数据进行过滤与转义,防止XSS
数据权限校验,数据越权访问
上传文件安全检查,重命名后单独存放
关键的交易操作会需要重新输入(密码、短信验证码、安全盾)等信息
评论