Hero Image
OWASP 十大网站安全风险 (三):敏感信息泄漏

OWASP 十大信息安全主题 注入攻击 (Injection) 无效身份认证(Broken Authentication 敏感信息泄漏(Sensitive Data Exposure) XML外部处理器漏洞(XML External Entities (XXE)) 无效存取控管(Broken Access Control) 错误设置安全系统(Security Misconfiguration) 跨站攻击(Cross-Site Scripting (XSS)) 不安全的反序列化漏洞(Insecure Deserialization) 使用已有漏洞元件(Using Components with Known Vulnerabilities) 日志和监控不足风险(Insufficient Logging and Monitoring) 敏感信息泄漏 许多网站和API没能很好的保护敏感信息,像金融,医疗,个人信息等等。攻击者可以通过窃取,篡改这些数据来进行信用卡诈骗,身份盗用,和 其他犯罪。敏感信息泄漏大多由于没有额外数据加密保护,像是没有在服务器端和传输过程中做加密保护,尤其是在和浏览器交换数据的过程。 了解敏感信息泄漏 在过去几年,敏感信息泄漏在网络安全中造成的最严重的影响。最常见的安全疏失就是没有加密,或者没有按照安全准则加密敏感信息。像是在密钥的产生和管理, 使用不安全算法,协议,网络等等,尤其是使用弱哈希密码加密存储数据。 敏感信息泄漏的威胁可能来自外部和内部。外部攻击者往往不会直接暴力解密,而是会在数据传输,与客户浏览器交互的过程中拦截,窃取明文, 然后对加密 系统攻击。内部威胁主要是有些员工运用权限漏洞直接下载敏感数据,如果数据只是在服务器端加密,没有多层加密的话,下载过程数据会自动解密,员工就拿到的 敏感信息的明文。 敏感信息一般包括个人身份确认信息,医疗资料,密码,私人信息,信用卡,还有一些法律要求管制的数据等等。 敏感信息泄漏不仅仅关乎经济,信用损失,还有伴随的法律责任。 所以对于敏感信息,要求在存储和传输的过程中都要额外加密保护。至少要考虑下面的具体问题: 数据传输过程中是否使用了非加密,非安全的协议, 像http, SMTP, 和 ftp 外部网络数据传输过程中是否一直是加密的,例如负平衡和应用前后台间的数据传输 敏感数据是否有备份 加密算法是否符合最近的安全标准,代码中是否有使用太老或者弱的加密算法 是否使用了默认加密算法,是否使用了弱的密钥,是否重用的密钥,是否有定期翻转密钥 与客户端数据交互的时候,是否强制使用安全加密通信

Hero Image
OWASP 十大网站安全风险 (二):无效身份认证

OWASP 十大信息安全主题 注入攻击 (Injection) 无效身份认证(Broken Authentication) 敏感信息泄漏(Sensitive Data Exposure) XML外部处理器漏洞(XML External Entities (XXE)) 无效存取控管(Broken Access Control) 错误设置安全系统(Security Misconfiguration) 跨站攻击(Cross-Site Scripting (XSS)) 不安全的反序列化漏洞(Insecure Deserialization) 使用已有漏洞元件(Using Components with Known Vulnerabilities) 日志和监控不足风险(Insufficient Logging and Monitoring) 无效身份认证 程序开发中,既要保证安全,又要有好的用户体验,身份认证,授权,和session管理很容易出现错误漏洞,攻击者可以利用这些漏洞来穿透认证检查,从而可以临时或者永久的使用其他人的账户。 了解无效身份认证 对于需要保存状态的应用程序,身份认证,授权,session管理等的设计和执行很容易出现漏洞。尤其是session管理,它是身份认证,授权等的基石,攻击者大多 会对过期令牌进行攻击。 攻击者有海量的有效用户名和密码组合,这些数据可以使用在 撞库攻击(credential stuffing attack) 默认管理员账户列表 自动暴力破解 字典攻击工具 攻击者能通过以上手段发现无效身份认证漏洞, 一般来说,攻击者只需要几个账户,或者一个管理员账户,就能侵入,破坏系统,这样可能会造成很严重的后果,例如 洗钱,盗窃身份,重要敏感信息泄漏 等等。 什么情况容易被攻击 允许撞库攻击 允许暴力破解 允许默认或者非常弱的密码,例如 “Password1” 和 “admin/admin”

Hero Image
NoSql也搞ACID:DynamoDB Transaction

先扯扯为啥用DynamoDB,简单说就是公司没有或者没人愿意干DBA,SRE也不想干这活。。。感觉到了cloud后,DBA都华丽转身大数据了,不屑于在搞RDS。 还有些公司搞"you write it, you deploy it,and you maintain it",一个组要负责自己的产品,从UI到DB,个个都要full-stack。DynamoDB就属于Developer完全可以搞定的, 不需要DBA或者SRE帮忙。 一般业务不需要多表join的,DynamoDB设计好了都没问题,还是有些dev说,我们的业务需要ACID,今天就来打脸了,Transaction is not a deal breaker for Dynamodb anymore。 DynamoDB Transaction保证ACID。ACID意思是atomicity, consistency, isolation, and durability。这里主要谈的是atomicity,同时操作 多个表或者行,结果要是all or nothing,全部操作成功,或者什么都不做。 两个Transactional API TransactWriteItems 一个transaction最多操作25个不用的items,每个item大小不超过400 KB,整个transaction大小不超过4 MB。 同一个transaction只能操作同一个item一次。 消耗双倍WCUs。 可以用client token来保持幂等(10 mins)。 TransactReadItems 一个transaction最多操作25个不用的GET,整个transaction大小不超过4 MB。 返回的是同步读的结果。 消耗双倍RCUs。 读写都不用锁,有冲突就会取消transaction,需要自己处理retry。注意,即使但transaction取消了,还是消耗同样的capacity units。 其他: transaction读写都不用锁,有冲突就会取消transaction,需要自己处理retry。注意,即使但transaction取消了,还是消耗同样的capacity units。 transaction必须在同一个AWS region transaction必须在同一个AWS 账户 transaction必须在DynamoDB里 例子 源码: https://github.

Hero Image
本地Docker安装Postgres 12 + pgadmin (支持Apple M1)

介绍 项目最近要升级Posgres数据库, 从9.6升级到12+。为了做一些migration测试,我本地要安装几个版本的Postgres,最方便的就是 用Docker安装了,没有版本冲突的问题,好管理,也方便删除。 另外建议使用docker-compose,或者stack,简单说就是可以data存在本地,这样每次重新启动,数据不会丢,可以重复使用。如果 是做integration testing,则可以每次启动一个新的container。 下面docker-compose文件里面还有pgAdmin,这样使用Postgres更方便。也可以使用自己喜欢的DB browser,我用IDEA(ultimate) 带的Database plugin。 支持 Intel CPU 我在MacOS下用了一段时间,没问题。 保存成docker-compose.yml文件 在文件路径下运行 docker-compose up -d 说明: user和password自己随意设置 volumes是本地保存数据库的路径 ports:默认是5432。我一般喜欢改成15432,项目多了,10000下的port很拥挤 pgadmin的email和password是页面登陆密码 pgadmin的volumes和ports跟Postgres性质一样 version: '3.5' services: postgres: container_name: pg12 image: postgres:12 environment: POSTGRES_USER: pg12 POSTGRES_PASSWORD: pg12 PGDATA: /data/postgres volumes: - postgres12:/Users/szhang/postgresql/pg12 ports: - "5432:5432" networks: - pg12 restart: unless-stopped pgadmin: container_name: pgadmin12 image: dpage/pgadmin4 environment: PGADMIN_DEFAULT_EMAIL: a@gmail.com PGADMIN_DEFAULT_PASSWORD: a@gmail.com volumes: - pgadmin12:/Users/szhang/postgresql/.pgadmin12 ports: - "27777:80" networks: - pg12 restart: unless-stopped networks: pg12: driver: bridge volumes: postgres12: pgadmin12: 支持 Apple M1 这个版本唯一不同在于Postgres image 是ARM版本的,专门支持最新的Apple M1芯片的电脑。另外多说一句,Apple M1电脑可以跑Docker, 但是很多Docker image还没有ARM版,所以目前用M1电脑做开发(需要docker)还不方便。

Hero Image
Micronaut + GraalVM 是不是真的香

微服务规模大了以后,传统build 的docker image就显得非常臃肿,启动慢,体积大,非常不利于scale, 资源消耗也大。一般提高方法就是使用轻量级模块注入,用什么,加什么, 并且不用大的框架,像Spring, Spring boot就 非常不推荐在为服务使用。。。 经过上面优化,性能会好一些,但没啥惊人变化, 因为base image还是openjdk,依赖注入,反射,注解之类 还是会降低启动速度。 GraalVM(https://www.graalvm.org/) GraalVM作为一款新型通用的虚拟机,不废话,单刀直入解决问题,启动快50倍,内存消耗少5倍。 为啥它这么牛,因为它用AOT(ahead-of-time)编译,可以快速启动和低内存消耗。官方列的优点: 高效 AOT 编译 (快速启动) 多语言 高级工具(调试,监控,profile等等) 后两项还没有特别感觉,因为公司后台主要用Java/Kotlin/Grrovy,没有多语言问题。高级工具这些,公司有统一的stack,也不准备用。 Micronaut(https://github.com/micronaut-projects/micronaut-core) Micronaut是一款现代, 基于JVM的全栈Java框架,适用于模块化搭建,易于测试的JVM应用,支持Java, Kotlin和Groovy. 它提供了编译时的依赖注入和AOP处理能力,并最小化反射和动态代理的使用。它应用有着更快的启动速度和更低的内存占用。 Micronaut + GraalVM (POC) 用Micronaut template创建一个App version: 2.3.3 language: Java 11 build: gradle test: jUnit feature: netty-server 创建一个简单的API @Controller("/hello") public class HelloController { @Get("/") public String index() { return "hello from Micronaut + GraalVM"; } } 添加lib到build.