设为首页 加入收藏

TOP

项目中必须对应的隐性需求-安全漏洞修复(一)
2019-09-17 17:00:28 】 浏览:55
Tags:项目 必须 对应 隐性 需求 安全漏洞 修复

WHAT

项目中必须对应的隐性需求-安全漏洞修复

 

WHY

    小时候下围棋,总乐于持白子。因为我的打法是“从那里来我哪里堵”,在防守中寻找对方的漏洞。这种作战方法是有底层的思想根因的:就是懒惰。不愿意去主动思考布局。

    在这一思想的引导下,我目前正面临着过去十多年积累起来的困境。记得大学之前,面对一个认识的人,我心里是有预期的。我大体知道这个人在想什么。慢慢的,除了我周围的亲人,其他人站在我面前我大脑一片空白。曾经以为这是因为我面对的环境更加复杂了。后来细想这不是本因,本因是我正一点点的失去获得常识的能力。

    小时候很爱大自己十岁的亲哥哥,他不喜欢我,视我为资源掠夺者。我想当时是遇到过一些事情,但不至于是什么忍受不了的大事。我却选择了逃避,在上大学时消除了自己的部分记忆。怕压力,第一份工作在一个二线城市世外桃源一样的大园子里上班。后来想换地方,找了现在的老公先给我铺路。因为毕业比同龄人略早些,所以在没有结婚压力的时候就结婚了,没有生子压力的时候就生娃了。仗着运气好嫁对了人,万事不操心,过着白痴一样的生活。不知己之痛,更不知别人之痛。所以常识渐失。

    电视剧《黄真伊》里面一句话:艺术最重要的是痛苦。后来想痛苦大概是最重要一种能力。在设定项目计划的时候,最重要的要解决痛点。很多人的成功都来源于梦想和渴望。而梦想和渴望就是求而未得之痛。下棋时更愿意花心思去布局的人必然是对成功渴望更大的人。棋未下,我已经输了。

    

    安全问题或许是一多半产品人员在提需求的时候都不会特意强调的东西,却是对技术人员来说必须要考虑的常识。XXX被DDos攻击,系统瘫痪。XXX数据泄露导致股价大跌,公司被起诉。最近风口浪尖上的脸书照片事件就是血淋漓的例子。一旦遇上,卷铺盖走人算是轻的了。如果技术人员不慎重对待,结果必然会如现在的我一样,陷入作茧自缚的困境。

 

HOW

    今天将一些产品或者上上下下都会考虑的显性安全需求(如合规需求)排除在外,总结下开发人员必备的安全设计。在我看来,这个如限流、降级一样,属于系统的稳定性范畴,当然很多人将其独立出来作为安全性范畴也是非常合理的。

    这类设计总结来说是用来解决两类问题。一个是自己不作死,另一个是不被别人搞死。

    

一.不作死

1.1 准入校验

    1.1.1 文本准入

    1.1.2 操作合理性准入

1.2 数据处理

    1.2.1 输入转义

    1.2.2 输出转义

    1.2.3 敏感信息加密

1.3 权限控制

    1.3.1 杜绝批量操作

    1.3.2 限制暴露范围

二.不被搞死

2.1 应对代码注入

    2.1.1 XSS攻击

    2.1.2 CSRF攻击

    2.1.3 mysql注入攻击

2.2 漏洞补丁升级

    2.2.1 弱口令漏洞

    2.2.2 开源代码漏洞

    2.2.3 文件上传漏洞

2.3 基础安全设施

    2.3.1 WAF

    2.3.2 安全审计

    2.3.3 风控

    2.3.4 安全监控

 

    上面的目录我先单独列一下,希望大家可以记住。都是平时开发中需要考虑的。下面稍详细的介绍一下。

 1.1.1 文本准入

    做业务需求有个常识,对于用户输入的每个字段都需要和产品经理讨论一下:什么类型、长度多少、允许的字符集范围、格式是否合法。这么做一方面是设计问题,包括产品设计、数据库设计,还有一部分是安全问题:一个数值型的字段肯定比一个粗放的文本型字段被攻击的可能性小,起码不会传到后端之后被当成脚本被执行。

1.1.2 操作合理性准入

    比如一个普通用户不能编辑另一个用户的个人信息。比如i申请公司服务器,一次申请1万台机器。比如流量准入,一台机器以超快的速度频繁访问一个网站的资讯信息,就可能不是真实用户操作而是爬虫。以上都会对系统安全性产生极大的影响。

1.2.1 输入转义 & 1.2.2 输出转义

    我在项目有个原则:尽量保存用户的原始信息。比如用户输入一个页面脚本编写方法的文章,在数据库中保存的时候,尽量只转义sql关键字(apache 里有现成的转义方法)而不转义html和js脚本。html和脚本在显示再做转义。

1.2.3 敏感信息加密

    最基本的用户密码必须密文存储,并且不能明文出现在日志中。 其他信息如手机号、银行卡号等不能全文显示。一般的表示方法是XXX***XXXX。

1.3.1 杜绝批量操作 

    常规代码里的操作都必须是点对点的。批量操作,查询可以,只要能保证存储压力够。要是批量的执行XXX,应用场景有:比如临时的一次性操作。如果是常规操作,那就必须走审批,而且一次操作必须有个数限制,保证出了问题影响范围也可控。

1.3.2 限制暴露范围

    开发一整套系统内部各个模块通常有内网域名、外网域名或者dubbo这种服务注册发现机制。这种区分出了传输效率、成本、资源等考虑之外,还有一个很重要的因素就是安全。一个外网服务肯定要比一个内网服务更可能遭到攻击。

 

2.1.1 XSS攻击

    XSS(Cross Site Scripting)攻击全称跨站脚本攻击,是为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆。它是一种在web应用中的计算机安全漏洞,它允许恶意web用户将代码植入到提供给其他用户使用的页面中。

危害包括:

1>盗取各类用户账号,如机器登陆账号、用户网银账号、各类管理员账号

2>控制企业数据,包括读取、篡改、添加、删除企业敏感数据的能力。

3>盗窃企业重要的具有商业价值的资料

4>非法转账

5>强制发送电子邮件

6>网站挂么

7>控制受害者机器想其他网站发起攻击

2.1.2 CSRF攻击

    CSRF(Cross-site request forgery),中文名称:跨站请求伪造。也被称为:one click attack/session ridi

首页 上一页 1 2 下一页 尾页 1/2/2
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇数据库连接池及数据库连接获取(.. 下一篇FaaS技术框架

最新文章

热门文章

Hot 文章

Python

C 语言

C++基础

大数据基础

linux编程基础

C/C++面试题目