关于web端漏洞及安全性问题的浅谈
前言:
- 本人以总结自己的错误,以及经验分享为初衷记录该文,希望可以帮助到一些新加入的朋友们
- 前段时间在部署了以python语言开发,django框架工具进行搭建的web后端程序,在反向nginx服务器,及uwsgi web服务器的支持下,并发数稳定在2000左右(小型企业非对外开放项目)
由于项目的特殊性,也是作为小白,第一次接触到项目的部分的安全性问题*
项目试运行阶段,甲方发送人工渗透测试检测漏洞6处低危漏洞,11处中危漏洞,2处高危漏洞,对于一个项目开发人员,看到自己的项目有许多漏洞,还是挺意外的。
1.登陆页面账号密码明文传输:
输入账号密码,使用BP进行抓包,可以看到账号/密码的明文。
检测使用抓包工具,抓取数据包,发现居然有明文的用户名密码。
很清楚的看到这个数据包的是遵循http协议的,结构体以空格分开的是TCP数据包的body内容(这是TCP的数据包结构,要熟系http协议和tcp,这里有一篇之前的tcp的讲解),也就是我们需要接收的数据资源。但是赤裸裸的暴露出来内容,这样的漏洞是web的首要也是最重要的问题。我们需要对数据包进行加密。
提到发送包的加密,相信很多新人都没有注意这个问题,我们的密码需要加密否则人人都可以登录了。
这个位置有两种解决方案:
(1). HTTPS协议,加入ssl安全证书
- http协议数据传输模式:明文传输,网站或相关服务与用户之间的数据交互无加密,极易被监听,**甚至篡改。
- https协议数据传输模式:在HTTP下加入了SSL 层,是数据传输变成加密模式,从而保护了交换数据隐私和完整性,简单来说它就是安全版的 HTTP。
这里不单独列举http协议和https协议的区别了,我会单独编写关于http协议和https协议的区别,及安全性的问题。
(2). 用户名密码进行MD5加密认证传输
由于漏洞的急切修复,协商决定先将数据使用md5加密方式对用户名密码进行加密传输
- 首先保障的第一点就是,我们的用户名密码有人恶意拿到后,无法登录。
如果只是单纯做一次加密想想会有什么问题?(图中session写错)
当有人恶意拿到数据用户名密码的md5值,再次进行登录还是可以登录上去,所以建议后端再进行一次加密工作,建立多一道防线。
2.登陆页面,前端验证码失效:
做过爬虫的朋友应该知道,一个优秀的爬虫,一定要攻克各种困难,如登录时的重重验证。
- 这里其实没什么,只是为了偷懒(看到的朋友,千万别学我),让前端工程师把验证码一块做了,相当于前端单独的做了一方的认证,后端并没有进行验证码验证。
当然由于是试运行阶段,还需要时间迭代过程功能,加强安全验证,之后的语音验证,验证码验证,图片验证滑块等,是基础的安全需要补足的地方
3.越权:
- web常见的权限管理,指普通用户登录和管理员用户登录不同的界面显示和一些权限应用等,出现的问题是使用test用户登录后,在后台修改发包内容后,将root用户名称发送后,立即获取了root用户的所有权限.
- 问题出现的原因在于对用户的权限认证,我自己在调试阶段暂时注销了验证方便调试,但是同样也是具有一定安全性的问题,在某个用户登录后,应该产生该用户对应的token,session作为当前用户的唯一标识,每次请求应该携带token和用户名,如果用户名称与所产生的token不符合,将提示越权操作,使访问失效,从而避免数据泄露,权限越权等安全性问题。
4.服务器信息泄露:
- 这里使用服务器版本是nginx1.16.1,在甲方的要求下,这个位置应该不能显示服务器版本号。这样的做法无疑是暴露自身服务的潜在性威胁,涉及服务器相关的信息应该把能省略的信息尽量省略,并且尽量减少信息,版本,型号作为公共资源。
- 该位置在nginx服务器配置文件中修改,这里不做多的赘述。
5.真实路径泄露:
- 在项目正式上线前,我们应该将所有的调试状态修改,如上图,相信很多小伙伴在调试的时候经常会看到这个页面,访问某个不存在的,或者报错页面信息时,出现了服务的真实路径,这些都是极其敏感的信息,都是不允许出现在用户面前的。
- 在django中,配置文件将工程的debug=False模式修改即可解决这个问题,希望大家记得,不要偷懒。
6.CORS (Cross-Origin Resource Sharing) origin validation failure【跨域资源共享来源验证失败】
- 简洁一点,理解跨域!
- 一般本地访问你的web数据是通过自己的web文件下的js,html等,现在通过别人电脑(域名)访问你的web数据就是来源非你自己的电脑,就好比远程控制,你不同意他的远程控制,他就无法操作你的电脑。
- 那怎么理解呢来源验证失败呢?
- 在每一个http请求发送的时候,协议中会自带请求域名,也就是我们在判断数据是否可以给的时候,我们先验证你的请求头里是否包含我认为是安全可信任的域名。如果你是我的会员名单,自然我可以让你访问,否则我将对你说no。
- 如果发现你的域名来自国外,或者一些黑名单,我可以拒绝你的请求,或者自己的该项目为不对外开发的服务,不允许任何非电脑前的用户远程进行操作,我们就只允许本地同源的html,js操作即可。这个时候关闭跨域配置,外部域名人员将无法从外部域名获取资源。
- 从而实现安全性,当然我们也可以配置允许跨域,在配置中设置跨域的白名单即可,不同框架配置大同小异,这里不做修改示例。
码字不易,还望多多指教,如有帮助,点赞鼓励,谢谢~!!