相当详细的Web安全原则,转载至此做个备忘吧。
Web安全原则
1.认证模块必须采用防暴力破解机制,例如:验证码或者多次连续尝试登录失败后锁定帐号或IP。
说明:如采用多次连续尝试登录失败后锁定帐号或IP的方式,需支持连续登录失败锁定策略的“允许连续失败的次数”可配置,支持在锁定时间超时后自动解锁。
2.对于每一个需要授权访问的页面或servlet的请求都必须核实用户的会话标识是否合法、用户是否被授权执行这个操作,以防止URL越权。
说明:防止用户通过直接输入URL,进行URL越权,请求并执行一些页面或servlet;建议通过过滤器实现。
3.登录过程中,往服务器端传递用户名和口令时,必须采用HTTPS安全协议(也就是带服务器端证书的SSL)。只提供本机接入、登录,做设备管理使用的场景暂时不要求。
说明:如果在客户端和服务器间传递如帐号、口令等敏感数据,必须使用带服务器端证书的SSL。由于SSL对服务端的CPU资源消耗很大,实施时必须考虑服务器的承受能力。
4.对用户的最终认证处理过程必须放到服务器进行。
5.用户产生的数据必须在服务端进行校验;数据在输出到客户端前必须先进行HTML编码,以防止执行恶意代码、跨站脚本攻击。对于不可信的数据,输出到客户端前必须先进行 HTML 编码。
6.使用主流Web安全扫描工具扫描Web服务器和Web应用,不存在“高”级别的漏洞。
7.非嵌入式产品的Web应用,应使用预编译语句PreparedStatement代替直接的语句执行Statement,以防止SQL注入。
数据库安全
外购数据库、开源数据库、华为自研数据库都应进行安全配置,保证不出现安全漏洞。
2.使用单独的操作系统帐号来运行数据库;数据库中的敏感文件(如:Oracle数据库的init.ora、listener.ora等)需要严格控制访问权限,只能被数据库进程运行帐户和DBA帐户读写;对数据库帐户授予的权限进行严格清晰的划分,所有数据库帐户只能具备执行其任务的最小权限;对于有监听器功能的数据库(如Oracle的listener.ora)需要设置监听器密码或者设置为本地操作系统验证。
3.使用主流或华为指定的系统扫描软件进行安全扫描,不存在“高”级别的漏洞。
敏感数据保护
系统对敏感数据的存储、传输和处理需保证数据安全,并遵从适用国家和地区的法律和法规要求。
敏感数据定义:包括但不限于口令、银行账号、个人数据(单独使用该数据或者结合其他信息可以识别某个活着的自然人的数据,包括:最终用户姓名、帐号、主叫和被叫号码、通信记录、话单、通信时间、定位数据等)。
1.口令不允许明文存储在系统中,应该加密保护。在不需要还原口令的场景,必须使用不可逆算法加密。对银行账号等敏感数据的访问要有认证、授权和加密机制。口令文件必须设置访问权限控制,普通用户不能读取或拷贝加密的内容。如果帐户文件/数据中含有口令又必须所有用户可访问,则需将帐户文件/数据与口令文件/数据分开。
注:对于业界第三方主流软硬件(如操作系统、数据库、Web容器)自身提供的口令功能,不受本条限制。
2.在非信任网络之间进行敏感数据(包括口令,银行帐号,批量个人数据等)的传输须采用安全传输通道或者加密后传输,有标准协议规定除外。
3.禁止使用私有加密算法。
说明:
1)对称加密算法建议使用:AES192及以上强度;
2)密钥交换算法建议使用:DH1024;
3)数字签名算法建议使用:DSA1024、ECDSA192;
4)非对称算法建议使用:RSA2048、ECC192;
5)HASH(哈希)算法建议使用:SHA256及以上强度;
6)HMAC(基于哈希的消息验证码)算法建议使用:HMAC-SHA256;
4.用于敏感数据传输加密的密钥,不能硬编码在代码中。
在敏感数据的安全传输上,优先使用业界的标准安全协议(如SSH v2/TLS1.0/SSL3.0/IPSec/SFTP/HTTPS等),并确保密钥可配置;如果是由产品自身实现安全传输过程,则优先使用Diffie-Hellman密钥交换算法,如果使用预置共享密钥等其他方法,也必须保证该密钥可配置和可替换。
5.禁止在日志、话单等文件中记录口令、银行账号、通信内容等敏感数据;
6.尽量避免在日志、话单中记录个人数据,如果必须记录个人数据,则所有数据必须进行结构化存储或适合于进行匿名化提取;
1)尽量避免在日志中记录个人数据,如果必须记录,在个人数据之前或之后加统一的标记,以区别于其他非个人数据。
2)尽量避免在话单中记录个人数据,如果必须记录,则话单必须进行结构化存储,字段间必须由统一的分隔符分开,每行的字段按列严格对应。
7.有个人数据导出功能的产品发布时必须同时提供对个人数据进行过滤或匿名化处理和功能或工具;
8.严格限制导出功能的权限,对导出功能的使用必须有日志记录。
9.涉及个人数据的采集/处理的功能须提供安全保护机制(如认证、权限控制、日志记录等),并通过产品资料向客户公开。
10.在正常业务流程和标准协议之外,禁止出于故障定位目的进行用户精确位置信息定位。如需处理用户精确位置数据,应有华为的明确需求,并在方案设计时,给予用户随时撤回同意的机会。
口令安全策略管理
1.设置口令时,默认检测口令复杂度,口令至少满足如下要求:
1) 口令长度至少6个字符(特权用户至少8个字符);
2) 口令必须包含如下至少两种字符的组合:
-至少一个小写字母;
-至少一个大写字母;
-至少一个数字;
-至少一个特殊字符:`~!@#$%^&*()-_=+|[{}];:’”,<.>/? 和空格
3) 口令不能和帐号或者帐号的逆序相同;
若设置的口令不符合上述规则,必须进行警告。
2.系统必须提供锁定用户的机制。可选择如下两种方式之一:
方式一:当重复输入错误口令次数(默认3次,次数系统可以设置)超过系统限制时,系统要锁定该用户。
方式二:系统还可以设置下次允许输入口令的间隔时间加倍,采用这种方式时,用户可以不设置自动锁定。
3.可设置自动解锁时间(只适用于由于口令尝试被锁定的用户)
1) 对于口令尝试N次失败被锁定的用户,系统要能够设置自动解锁时间,建议默认解锁时间为5分钟。
2) 用户被锁时间达到预定义时间,可自动解锁该用户,或者也可通过安全管理员手工解锁该用户。
3) 在锁定时间内,仅能允许应用安全管理员角色所属帐号手动解锁该用户。
4.操作界面中的口令不能明文显示,键入口令时不能明文显示出来(操作界面中的输入口令可不显示或用*代替),包括在终端上打印或存储在日志中时也不能明文显示口令,即使是内存中的明文口令(如登录期间),也应在使用后立即覆盖。
5.口令输入框不支持拷贝功能。
6.对于系统内置帐号的缺省口令,口令应符合复杂度的要求,并在客户资料中提醒用户修改。
7.用户可修改自己的口令,需满足如下要求:
1) 用户修改自己口令时必须验证旧口令;
2) 不允许修改除自身帐号以外的帐号的口令(管理员除外)
8.口令不能在网络中明文传输,口令等认证凭证在传输过程中必须加密,使用高安全等级的加密算法。
说明:
1)对称加密算法建议使用:AES192及以上强度;
2)密钥交换算法建议使用:DH1024;
3)数字签名算法建议使用:DSA1024、ECDSA192;
4)非对称算法建议使用:RSA2048、ECC192;
5)HASH(哈希)算法建议使用:SHA256及以上强度;
6)HMAC(基于哈希的消息验证码)算法建议使用:HMAC-SHA256;
9.口令在本地存储时必须加密,需满足如下要求:
1) 口令不能够明文写入日志文件、配置文件以及cookie中;
2) 口令文件必须设置访问控制,普通用户不能读取或拷贝加密的内容。
10.产品配套资料提供清晰的帐号、口令清单。
说明:华为提供用户清单模板
安全资料
针对售前、开局、现网运维几个阶段,提供配套安全方案、资料。
2.产品发布前提供产品通信矩阵。描述机器/网元/模块间的通信关系,包括:通信使用的端口、协议、IP地址、认证方式、端口用途信息等。
说明:华为提供通信矩阵模板。
3.产品发布前提供防病毒软件部署指南。描述防病毒软件部署前的准备、流程、执行步骤、失败后回退处理,以及病毒特征库升级配置指导(Windows系统平台必选)。
4.产品发布前提供安全配置/加固指南。
描述如下内容:
-安全加固及检查,主要包括操作系统、数据库或WEB服务器等加固内容,需要包含具体的加固内容和操作步骤(必选)。
-应用的安全配置,针对产品业务安全应用,需要启用哪些安全选项,配置哪些内容。(对于需要通过对产品开局时进行安全策略配置才能生效的安全功能,需要提供此部分内容)。如果没有应用的安全配置,命名为安全加固指南。安全加固指南是必须的。
5.产品发布前提供安全维护手册。从解决方案角度提供业务日常安全维护方面的指导,包括安全补丁、安全配置、防病毒软件例行检查等,指导维护人员例行进行安全维护。
操作系统安全
无论是使用通用操作系统(Windows、Linux、Unix等)还是嵌入式操作系统(如VxWorks、pSOS等),系统都应该保证软件及软件运行环境的安全。
注:系统指交付给客户运行的整体系统,包括自研的软件、软件运行的操作系统及应用服务在内。
1.使用主流漏洞扫描软件进行安全扫描,不存在高风险级别的漏洞。
2.基于通用操作系统的新发货产品“操作系统加固+操作系统补丁”预装率=100%;对于不在生产环节预安装的产品,需要在正式发布的版本中包含默认的安全策略文件,并在产品资料中说明加固要求和操作步骤。
说明:
1)华为提供的操作系统,产品版本应基于最新的操作系统安全补丁进行开发和兼容性测试。
2)合作方提供的操作系统,合作方需在版本交付前对操作系统安全补丁进行兼容性测试并随版本发布,并根据CIS标准对操作系统进行加固并随版本发布。
3.使用Windows操作系统的产品,产品需要使用主流防病毒软件进行进行兼容性测试。
说明:
1)华为提供的Windows操作系统,合作方需使用主流防病毒软件或华为指定的防病毒软件进行兼容性测试;
2)合作方提供的Windows操作系统,产品需要缺省配套华为指定的防病毒软件,并对防病毒软件进行兼容性测试。
协议与接口防攻击
系统应具备基本的防攻击能力,对影响自身的常见攻击具备防御能力等。注:系统指交付给客户运行的整体系统,包括自研的软件、软件运行的操作系统及应用服务在内。
1.系统所有的对外通信连接必须是系统运行和维护必需的,对使用到的通信端口在产品通信矩阵文档中说明,动态侦听端口必须限定确定的合理的范围。通过端口扫描工具验证,未在通信矩阵中列出的端口必须关闭。
说明:
1)华为提供通信矩阵模板。
2.尽量避免使用动态侦定端口的实现方式,在没有替代方案的情况下,如果必须使用,需满足如下要求:
1)、如果使用业界标准的协议(如RPC、FTP被动模式),并有一定的安全措施(如NFS安全配置、防火墙支持FTP被动模式等);
2)、如果自实现的方式,则动态侦听端口必须限定确定的合理的范围。
3.所有能对系统进行管理的通信端口及协议必须有接入认证机制,标准协议没有认证机制的除外。
4.对自研协议和业界非主流软件(包括非主流的开源软件)实现的协议要进行协议畸形报文攻击测试。
5.设备外部可见的能对系统进行管理的物理接口必须有接入认证机制。
监听接口及防止非法监听
产品开发合法监听接口应遵循国际标准及所在国的法律要求。
2.在华为对合法监听接口有需求的情况下,合作方需根据华为提供的监听功能或接口的文件中的要求开发。
说明:对提供合法监听接口的产品版本的要求(二选一)
1)产品提供两个版本的软件安装包:一个支持合法监听,一个不支持合法监听。根据市场的安全要求,选择对应的软件安装包进行部署。
2)产品提供软件安装包拆分为:基本软件安装包和合法监听插件安装包。根据市场的安全要求,选择是否安装合法监听插件安装包。
3.在正常业务流程和标准协议之外,禁止提供采集最终用户原始通信内容(语音类、短信/彩信类、传真类、数据业务类)的功能,即使出于保障网络运营和服务目的。
注:
1) 除了语音类、短信/彩信类、传真类、数据业务类信息属于通信内容外,最终用户的即时消息、E-Mail信息、URL同样属于通信内容;
2) 允许使用debug功能,但debug信息中不允许包含口令、银行账号、通信内容等敏感数据。
《 “[collect]华为内部的Web安全原则” 》 有 21 条评论
HMAC
http://baike.baidu.com/item/hmac
https://blueying.gitbooks.io/wan/content/safety/hmac.html
Hash, MAC,HMAC
http://www.cnblogs.com/songhan/archive/2012/07/29/2613898.html
HMAC算法安全性浅析
http://www.ftsafe.com.cn/service/kbase/infomation-2
什么是 HMAC-MD5?
https://www.zhihu.com/question/19816240
HMAC-MD5算法原理及实现
http://swq.jgz.sh.cn/?p=681
HMAC 算法
http://louisrb.blog.163.com/blog/static/756801292010014102633126/
HMAC加密算法
http://www.jiamisoft.com/blog/2800-hmacjiamisuanfa.html
HMAC计算、HMAC-MD5、HMAC-SHA1、HMAC-SHA256、HMAC-SHA512在线计算
https://1024tools.com/hmac
Web开发之跨域与跨域资源共享
http://www.devsai.com/2016/11/24/talk-CORS/
你所不知道的跨域资源共享(CORS)
http://www.devsai.com/2016/12/15/little-know-cors/
OWASP 安全编码规范快速参考指南
https://www.owasp.org/images/7/73/OWASP_SCP_Quick_Reference_Guide_(Chinese).pdf
PHP安全编码规范之安全配置篇
http://blog.topsec.com.cn/ad_lab/audit-defanse/
安全编程
http://staff.ustc.edu.cn/~sycheng/sst/lectures/ch08_Secure_Programming.pdf
面向程序员的安全编码相关的资料收集
https://github.com/stanislaw/awesome-safety-critical
如何安全的存储用户密码?
https://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659599059&idx=1&sn=af9af208d412c8dad088b538c72260ed
加盐哈希密码的正确姿势
https://crackstation.net/hashing-security.htm
http://wps2015.org/drops/drops/%E5%8A%A0%E7%9B%90hash%E4%BF%9D%E5%AD%98%E5%AF%86%E7%A0%81%E7%9A%84%E6%AD%A3%E7%A1%AE%E6%96%B9%E5%BC%8F.html
加盐密码保存的最通用方法是?
https://www.zhihu.com/question/20299384
即使被拖库,也可以保证密码不泄露
http://blog.coderzh.com/2016/01/10/a-password-security-design-example/
设计安全的账号系统的正确姿势
http://blog.coderzh.com/2016/01/03/security-design/
很好的Web安全相关资料收集
https://github.com/qazbnm456/awesome-web-security
应用安全体系架构备忘录
https://www.secpulse.com/archives/65468.html
https://www.owasp.org/index.php/Application_Security_Architecture_Cheat_Sheet
常规web渗透测试漏洞描述及修复建议
http://blog.51cto.com/eth10/2049721
常见 Web 安全攻防总结
https://zoumiaojiang.com/article/common-web-security/
`
XSS
非持久型 XSS
持久型 XSS
基于字符集的 XSS
基于 Flash 的跨站 XSS
未经验证的跳转 XSS
CSRF
CSRF 原理
预防 CSRF
SQL 注入
SQL 注入原理
如何预防 SQL 注入
命令行注入
DDoS 攻击
网络层 DDoS
网络层 DDoS 防御
应用层 DDoS
应用层 DDoS 防御
其他 DDoS 攻击
流量劫持
DNS 劫持
`
0d1n – 自动化 Web 安全扫描器
https://github.com/CoolerVoid/0d1n
ezXSS – 跨站漏洞辅助测试工具
https://github.com/ssl/ezXSS
sonarwhal v1 ,一款 Web 检查(Linting)工具
https://blogs.windows.com/msedgedev/2018/04/19/sonarwhal-v1-linting-tool-for-web/
RTA – 一款用于检测公司7层资产中的安全漏洞的智能扫描器
https://github.com/flipkart-incubator/RTA
在 CORS 配置 Origin 不当的情况下的利用方式
https://www.soffensive.com/2018/04/exploiting-misconfigured-cors-null.html
浅谈非常态SQL注入防护,提升数据库安全
https://www.sec-un.org/%E6%B5%85%E8%B0%88%E9%9D%9E%E5%B8%B8%E6%80%81sql%E6%B3%A8%E5%85%A5%E9%98%B2%E6%8A%A4%EF%BC%8C%E6%8F%90%E5%8D%87%E6%95%B0%E6%8D%AE%E5%BA%93%E5%AE%89%E5%85%A8/
Jenkins 错误配置导致的 RCE 漏洞实例
https://blog.securitybreached.org/2018/09/07/rce-jenkins-instance-dosomething-org-bug-bounty-poc/
零基础如何学习 Web 安全?
https://www.zhihu.com/question/21606800
绕过浏览器SOP,跨站窃取信息:CORS配置安全漏洞报告及最佳部署实践
https://www.jianjunchen.com/post/cors%E5%AE%89%E5%85%A8%E9%83%A8%E7%BD%B2%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5/
`
一、背景
1.1 从 SOP 到 CORS
1.2 CORS 简介
1.3 CORS 基本用法
二、CORS 错误配置问题总结
2.1 反射 Origin头
2.2 Origin 校验错误
2.3 信任null
2.4 HTTPS域信任HTTP域
2.5 信任自身全部子域
2.6 Origin:*与 Credentials:true 共用
2.7 缺少 Vary:Origin头
三、CORS 部署现状评估
四、讨论与防御
4.1 标准组织与厂商响应
4.2 CORS 部署最佳实践
五、总结
六、参考文献
`
CORS漏洞扫描工具CORScanner
https://github.com/chenjj/CORScanner
HTTP API 认证授权术
https://coolshell.cn/articles/19395.html
`
本篇文章会覆盖如下技术:
HTTP Basic #不推荐
Digest Access #不推荐
App Secret Key + HMAC #(一般公司)不推荐
JWT – JSON Web Tokens #OK
OAuth 1.0 – 3 legged & 2 legged #OK
OAuth 2.0 – Authentication Code & Client Credential #OK
`
将敏感数据排除在日志之外的七个最佳实践(Seven Best Practices for Keeping Sensitive Data Out of Logs)
https://medium.com/@joecrobak/seven-best-practices-for-keeping-sensitive-data-out-of-logs-3d7bbd12904
`
#1 Compartmentalize Sensitive Data
#2 Keep Sensitive Data Out of URLs
#3 Redact Data Where Possible
#4 Structured Logging with a Blacklist
#5 Code Review
#6 QA and automated testing
#7 Automated alerts in logging system
==
区分敏感数据
不要让敏感数据在URL中出现(用POST而非GET)
尽可能地重写/修订数据
在结构化日志打印的时候使用黑名单的方式
代码评审
QA和自动化测试
在日志系统中添加自动化告警
`
https://blog.twitter.com/official/en_us/topics/company/2018/keeping-your-account-secure.html
日志中的用户隐私安全
https://insights.thoughtworks.cn/user-privacy-security/
保护日志中的用户隐私数据
https://wangbaiyuan.cn/protecting-user-privacy-data-in-logs.html
`
首先:确定什么是隐私数据
一、解耦隐私字段
二、避免在URL中出现个人隐私信息
三、对象打印重写toString方法
四、结构化日志输出时屏蔽隐私字段
五、将日志代码审查纳入Code Review
六、个人信息泄露测试纳入QA和自动化测试
七、在日志收集器上传前“打码”隐私信息
八、日志系统中配置个人隐私信息的监控告警
`
浅谈硬编码密码及其扫描工具
https://mp.weixin.qq.com/s/QDc-SyOYtCAx_G-4jWbLKg
`
# 总结
最好的办法就是:
1. 先用【通用正则表达式】进行粗筛,把能够命中的都先捞出来;
2. 再用【类似于字符串墒值检测的方法】对上一步匹配的结果进行过滤,排除明显不符合密码规范的内容就可以得到一个比较理想的结果了——误报不高,漏报不多。
理论上你还可以用其它完全独立或混合的方法来发现不容易被正则匹配到的密码,但是老实说,人都难以理解的你凭什么认为机器或是算法自己就能进行准确识别?
==
密码是对服务、系统和数据的访问权限进行授权的数字身份凭证,常见的密码有API密钥、非对称私钥、访问Token等。硬编码密码(Hardcoded Secret),或称嵌入式密码(Embedded Secret),是指将密码以明文方式直接写入代码中。这种处理方式极大地提高了攻击者命中密码的概率,使服务或系统暴露在风险中,容易造成严重损失。针对此问题,本文详细讨论了硬编码密码的成因、危害及治理方法;另外,本文从安全人员角度出发,对现有的硬编码密码检测工具的算法进行了深入调研,并提出了我们的自动化检测工具。
# 01 硬编码密码的成因及类型
随着互联网组织转向云架构、SaaS 平台和微服务,密码等数字身份验证凭证的数量和多样性正在快速增长。与此同时,企业也不断推动更短的发布周期,**开发人员面临巨大时间压力的同时,需要处理的密码量比以往任何时候都多。许多开发人员采取捷径,选择使用硬编码的方式处理密码。**
…
除了程序代码中,这些硬编码还容易出现在基础设施配置文件、监控日志、运行日志、堆栈调试track记录、git历史中。所有类别的硬编码密码都使企业暴露在攻击之下。
# 02 硬编码密码的危害
硬编码密码主要对安全和研发两方面具有危害:
1. 削弱系统安全性
攻击者常通过公共代码库或反编译分析获得硬编码密码字符串,利用密码访问敏感数据或获取敏感操作权限。攻击者还可以进一步扩大攻击范围,进行数据勒索、帐户操纵、帐户创建、通过用户数据进行利用等,使得企业和用户都遭受严重损失。在以下案例中,攻击均是从密码的泄露开始的:2014年,Uber数据库被未经授权访问,导致数千名Uber司机私人信息的数据被泄露[7];2016年,Uber又因外部的未授权访问导致5700万用户的个人信息被泄露;2018年,Github和Twitter[10]在内部日志系统中以明文方式存储密码,分别涉及2700万和3.3亿用户数据泄露;2020年,用户在Github仓库中发现了星巴克的API密钥,涉及重大信息泄露[8];2021年,黑客组织 Sakura Samurai 在一次重大数据泄露事件中获得了访问联合国 (UN) 员工私人数据和系统的权限[9]……由硬编码密码导致的安全事故层出不穷,也不断有相关CVE和CWE被披露。
2. 不易于程序维护
硬编码密码的修复较为困难,密码一旦被利用无法轻易被修正。对于正在线上运行的服务或系统,修复硬编码密码问题需要停服重新发布。大型企业的服务流量较大,服务间还存在依赖,则需要灰度发布,修复流程更长,其间可能持续受到攻击者威胁。
密码的蔓延也使维护变得困难。与传统凭证不同,密码旨在分发给开发人员、应用程序和基础设施系统,这将不可避免地使开发中使用的密码数量增加,一个密码可能出现在代码中多处位置,这进一步增加了修复的难度。
此外,开源的代码造成密码泄露,即使在源码中删除硬编码密码,也会残留在git历史里。
# 03 如何治理硬编码密码
企业代码中的硬编码密码问题日益严重,只有通过安全人员和研发人员的共同协作才能解决。源代码中的密码泄露很难彻底避免,但与其他漏洞一样,它完全由内生因素决定:开发人员需要访问更多的资源,以更快的速度构建和部署。这意味着只要有足够的纪律和教育,再加上正确的工具,就有可能大幅改善这种情况。
从开发人员角度,需要注意尽量避免将密码以明文形式写入代码中。代码中需要对密码进行校验时,对入站身份验证可使用强单向散列函数进行密码模糊化,并将这些散列结果存储在具有适当访问控制的配置文件或数据库中;对出站身份验证,可将密码存储在代码之外的一个经过严格保护的、加密的配置文件或数据库中,该配置文件或数据库不会被所有外部人员访问,包括同一系统上的其他本地用户[13];大型企业可以使用KMS服务进行一站式密码管理。
从安全人员角度,应尽量做到风险左移,尽早发现密码泄露,帮助开发人员降低修复成本。可通过代码检测扫描,将硬编码密码检测集成到开发工作流程中,提前发现硬编码密码问题。
04 硬编码密码检测算法
4.1 正则表达式匹配
(1)针对各种特定平台密码的表达式
(2)不针对特定平台的通用的表达式
4.2 熵字符串编码检测
05 硬编码密码检测工具研发实践:Gold-digger
5.1 工具设计
为服务于全公司研发环境,Gold-digger工具有如下需求
编程语言无关:公司各业务使用的编程语言不同,Gold-digger需要无障碍地应用于所有编程语言代码中。
模块化,方便扩展迭代:为了根据测试反馈结果不断提高效果,Gold-digger需要长期不断迭代。
能够集成到软件开发生命周期中:Gold-digger侧重预防,需要工具集成在CI/CD管道中,从源头遏制密码泄露风险。
高精确率召回率:Gold-digger的设计初衷之一是节约人力成本,为降低审计、维护和运营压力,必需尽可能准确、全面地检测密码。
基于上述需求,Gold-digger的架构主要分为四个模块:核心引擎、转换器、检测器、过滤器。
5.2 数据对比
分析显示,Gold-digger检测的密码中大部分是通过通用正则表达式和熵字符串检测获得的。这是由于内部代码中包含的密码大多无明显前缀后缀特征,特定平台表达式检测不到。正因如此,大部分工具尽管定义了大量的特定平台的正则表达式但漏报率仍很高,例如trufflehog定义了700多种特定平台正则表达式,但通用正则表达式种类较少,故对特定平台表达式未覆盖到部分的检测能力较弱。Gold-digger可以利用通用正则表达式和熵字符串检测进行弥补,有效降低漏报。
密码检测的一大难点是避免来自非密码字符串的误报。Gold-digger通过多种启发式规则的过滤得到了较低的误报率。其他工具大量误报的主要原因则是正则表达式的匹配范围太宽泛又缺乏有效过滤手段,例如Gitleaks通过通用正则表达式识别到大量密码候选值,但其中既有真正的密码,又有appkey name、间接引用等,但未进行筛除。
`
Website Security Checklist: Protect Your Website in 2024
https://www.upguard.com/blog/the-website-security-checklist
`
以下是加固网站并大大提高网站服务器弹性的 13 个步骤。
What Why
1. Ensure sitewide SSL #(Encrypt website traffic)
2. Verify the SSL certificate #(Stay on top of expiration and trust)
3. Use SHA256 encryption #(Use the best encryption)
4. Disable insecure cipher suites #(Shore up vulnerabilities in SSL)
5. Obscure header info #(Keep your configurations private)
6. Enable HTTP Strict Transport Security #(Disallow unencrypted traffic)
7. Use HttpOnly cookies #(Prevent scripts from reading cookie data)
8. Use secure cookies #(Disallow unencrypted transmission of cookies)
9. Secure the web server processes #(Use best practice configurations)
10. Ensure form validate input #(Prevent form mishandling)
11. Protect against SQL injection #(Prevent form exploits)
12. Protect against DoS #(Maintain service through an attack)
13. Regularly test configurations #(Make sure the steps above stay true)
要做的操作 具体的原因
1. 确保全站 SSL #(加密网站流量,避免被窃听)
2. 验证 SSL 证书 #(关注SSL证书过期时间,保持可信度)
3. 使用 SHA256 加密 #(使用最佳加密技术)
4. 禁用不安全的密码套件 #(修补 SSL 的漏洞)
5. 隐藏头信息 #(保持配置的私密性)
6. 启用 HTTP 严格传输安全 #(禁止未加密的流量)
7. 使用 HttpOnly cookies #(防止脚本读取 cookie 数据)
8. 使用安全 cookie #(禁止未加密的 cookie 传输)
9. 确保网络服务器进程的安全#(使用最佳实践配置)
10. 确保表单验证输入#(防止表单处理不当)
11. 防止 SQL 注入 #(防止漏洞利用)
12. 防止 DoS #(在攻击状态下还能维持服务)
13. 定期测试配置#(确保上述步骤保持正确)
`