Python RSA公钥解密 RSA_public_decrypt

我们一般使用 RSA 的时候,都是公钥加密,私钥解密。

因为从设计上来说公钥大家都有,私钥只有一方有,这样更安全,但实际来说也可以私钥加密,公钥解密。openssl有对应实现,但Python没有,项目中需要用到,所以还得尝试实现下。

Python的rsa库虽然没有提供公钥解密但提供了公钥verification方法,里面有使用公钥解密signature的代码,可以依样画葫芦。

同时也支持了长文本解密(分段)。

不过在实际使用过程中,发现rsa_public_decrypt特别慢,起初认为是rsa算法的问题,因为rsa设计上也不是用来加解密较长的文本。一番定位发现是PublicKey.load_pkcs1比较慢,在我Mac上需要3061000 ns,当然一般来说不需要每次都导入公钥,但我实际场景有点特殊,每次公钥都不一样,这个导入操作需要再优化下。

一番定位发现是底层返回public key对象时有个consistency_check参数写死了True,表示会校验n和e是否互为质数,但n和key的位数有关,一般特别大,一般求GCD(最大公约数)使用辗转相除法,即非常耗CPU,这也是Python的弱势,所以比较慢。

但我的场景可以确定rsa key是合法的,因此可以不校验。在我本地测试仅需290000 ns,提高了一个数量级。

后记:

这个问题是早些年解决的,那时候还没有ChatGPT,不断搜资料,也搞了好久。不过这个问题ChatGPT现在还是不能直接给出答案,会使用rsa.decrypt(encrypted_message, public_key),但相关库并不支持这样。如果你了解 RSA 原理的话,稍加引导,它最终还是能给出一个非常接近的答案,调一调其实就能用了,不得不感叹科技的进步。

N天学会Go语言

之前一直有了解 Go 语言,但没系统的学习,最近兴趣盎然生计所迫,得学一学了。整体来说 Go 语法很简洁,有其它语言基础的话学起来很快的。本文记录了一些学习笔记,加深理解。

基础语法

学语言,最重要的就是官方教程(https://go.dev/tour/list),建议不要一开始就跟着杂七杂八的教程学习。

变量

我们都知道 Go 语言是强类型的语言,所以定义变量的时候需要定义其类型,但像 C、Java,都是把类型放在前面:

咋一看有些别扭,但这有讲究的,比如符合英语系自然语言习惯,还有写起来就很方便,更突出变量名而不是类型(而且类型可以省略),官方博客有更多的介绍:Go's Declaration Syntax。还有,Go 和 Python一样,不需要写分号。

也还有简写的方式,因为定义变量的时候其实类型是确定的,编译器很容易推导,可以不用写类型。

看到var i = 1是不是有 JS 和 Java lombok/JDK10 的感觉,这样就很亲切了。

Methods are functions

一个函数定义:func add(x int, y int) int {},参数类型,返回值类型一目了然,这里可以看出还是类型后置,这点其实后面 Python 3.5 加入类型提示(限制)也是这样:def add(x: int, y: int) -> int:。这里顺带提一下,Python、PHP 这些无类型声明的语言并不是真的无类型(动态类型,运行时检查),而且新版都增加了类型检查的语法,解决了重构等痛点问题。

方法和函数其实一样,只是接收方参数不一样。

不过 Go 的函数没有 Python 的那么强大,没有默认参数、关键字参数等,虽然说 Go 讲究简洁,但这些语法糖还是很有用的,典型场景就是 Python requests 库:https://docs.python-requests.org/en/latest/api/#requests.request

Defer

延迟调用,这个比较特殊,defer定义的操作会在方法 return 后执行,但比如传的参数就是定义时那样,官方例子修改下:

输出

这个有什么作用呢,其实类似 Java 中 try/catch 中的 finally,可以用于资源的清理(经典应用就是释放锁)。官方博客有介绍:Defer, Panic, and Recover

Pointers

Go 的指针语法上来看,比 C 简单些,没有特殊的指针变量,&就是取地址,*就是取值(或者定义指针类型),也没有指针运算(其实也可以)。说到指针,又会牵扯到一个话题,传值还是传引用,简单来说 Go 传的是值,但并不代表改动不影响原数据,因为 map、slice等,可以理解本身数据结构就是指针,这些类型修改会影响原有数据,表现和其它语言一致。还有一个就是性能问题,本能的觉得传引用(指针)性能更高(其实还会带来 GC 等问题),比如字符串。

输出为:

咋一看 s2, s3 都是一个新的内存地址,这不影响性能嘛。但再看看:

输出:

可以看出 Go 对字符串等有两个优化:

1. 定义变量 literals(字面量)一致时(s1 和 s2),会指向同一个地址。

2. 变量传值时(s3 := s1)复制的是 string 这个数据结构。

data 指针指向的内容没有复制。因为要存储这个新的结构体,所以 &s3 是这个结构体的内存地址,而 s1,s3 结构体中 data 指向的地址是一样的。

指针这块细节可能理解不是太准确,但意思是语言层面已经做了很多优化,正常使用即可,不要过度优化到处使用指针。 Continue Reading...

Python import机制探究

最近遇到一个需求,需要动态加载一堆 Python 模块,但是这些 .py 是 pb 文件生成的,无法控制命名,导致导入的时候各种报错。

目录结构

package1.py 内容

package2.py 内容

package3.py 内容

可以看见在 basic.package1 中导入了 package2、package3。我们在 main 文件中导入 basic 包。

这样肯定不行,报错了:ModuleNotFoundError: No module named 'basic'

sys.path

Google 一下或者稍微了解 Python 的就会知道,Python 导入非系统库需要指定 PYTHONPATH,Python 启动时会读取此环境变量并加入到 sys.path 中。我们可以打印下:

可以看到默认加载了当前项目目录、Python系统目录以及 dist-packages(通过 pip 安装的),我们把 temp_dir 目录加进去就行了。代码增加:

但还是会报错:ImportError: cannot import name 'package2' from 'calendar' (/usr/lib/python3.8/calendar.py),不过至少说明,加载路径是设置成功了,basic 包本身导入成功了,只是 from calendar import package2 执行失败了。

这个是一个经典错误,搞 Python 的都会遇到,那就是自己定义的包名不能和系统的重复,一般是改个名字或者加上命名空间,但是我们这个场景中,Python 文件是 pb 生成的,无法修改源文件,修改生成的文件也比较麻烦。也能解决,就是提高我们路径的优先级,改成 sys.path.insert(0, temp_dir) 加载完了再改回来。

BuiltinImporter

不过又有新的报错:ImportError: cannot import name 'package3' from 'math' (unknown location),有输出 import package2,看着还是导入了系统的 math 库,没有导入自己的,还没有显示路径。这里匪夷所思,卡了很久,继续单步调试代码和查阅资料,发现 Python 其实是支持多种导入方式,甚至可以自定义。importlib._bootstrap._find_spec 中,是循环 sys.meta_path 中的 Importer 哪个找到算哪个。我们可以打印下 sys.meta_path:

可以看见最前面有个 BuiltinImporter(具体是在 importlib._bootstrap._install 时注入的),唉,灵光一闪,math 就是一个内建库呀,这里结合源码猜测,C 的库(详见 sys.builtin_module_names)都是通过这个导入的。去掉这个就能导入成功了(记得加载完了还原回来)。

终于成功了:

sys.modules

不过,这里只是个 demo。实际情况比这个复杂,还是会报 ImportError: cannot import name 'package2' from 'calendar' (/usr/lib/python3.8/calendar.py),这里很奇怪,已经保证了加载的优先级,但为什么还不行呢?没办法,扒一下源码,终于找到了一点端倪。importlib._bootstrap._find_and_load 方法中,会先在 sys.modules 里面找,如果有则直接返回,官方文档也有相应说明。

所以还得排除已加载的情况

最终到此才彻底解决,完整 demo 代码:https://github.com/iyaozhen/python-import-test

参考资料

https://docs.python.org/3/library/importlib.html

妙用Hook来研究Python的Import机制,https://www.51cto.com/article/527713.html

Python3.7源码剖析之import,https://zhuanlan.zhihu.com/p/361720373

Python Requests Session set-cookie不生效的坑

我们知道 Python Requests库 中的 Session 模块有连接池和会话管理的功能,比如请求一个登录接口后,会自动处理 response 中的 set-cookie,下次再请求时会自动把 cookie 带上。但最近出现了一个诡异的事情,cookie 没有自动带上,导致请求 403。

一开始怀疑是登录接口错误了,没有 set-cookie,但抓包发现 response header 中有 set-cookie,打印请求的 response.cookies 也有需要的 cookie。又怀疑是 set-cookie 的格式不对或者其它问题,但用浏览器实际跑了下流程,发现系统一切正常,那基本就是 requests 库的问题了。

没办法,只能 debug 了,单步调试了几轮,基本了解了 requests 的处理方式,首先把请求参数转变为 Request 对象,然后对使用 prepare_request 对 Request 进行预处理,其中有一步 merge_cookies 的操作(还有各种其它处理),把传入的 cookies 和 self.cookies merge 到 RequestsCookieJar 对象上去,这一步也没啥问题,merged_cookies 变量也是对的。后续将预处理过的请求,通过内置的 http adapter 发送出去。http adapter 底层是通过 urllib3.poolmanager 获取到 urllib3.connectionpool 连接(这里是连接池的核心部分),再通过 conn.urlopen 实际发送请求。虽然跟踪了解到了整个请求逻辑,但最终发出的请求还是没有带上需要的 cookie。

问题定位一度陷入僵局,只能再回顾上面的流程,cookie 肯定就是在 merged_cookies 和 conn.urlopen 之间没的,再仔细观察发现,conn.urlopen 请求参数里面压根没有 cookie 字段。

查阅资料发现,urllib3 的作者说,连接池只处理底层连接,cookie 跟踪等事情应该上层来做。大胆猜测,那 cookie 应该是放在 header 里了,往前捣看看 request.headers 是怎么变动的(此时里面的 Cookie 字段确实不正确)。

再走查代码发现 prepare_request 里面是调用了 PreparedRequest.prepare,其中有一步 prepare_cookies,主要是调用了 cookielib.CookieJar.add_cookie_header 最终将 cookie 放到了 self.headers['Cookie']。但里面有个 request.has_header("Cookie") 的判断,header 中没有 Cookie 字段才会放,不知道为什么这么考虑(最新版 3.8 还是这样),估计是 merge cookie 比较麻烦,但问题确实就出在这里,这次请求之前,Requests Session 已经直接通过 headers['Cookie'] 设置了 cookie。复现代码(修改自官方示例):

虽然找到了问题的原因,但又不好解决,总不能不让直接操作 headers['Cookie'] 吧,先不说无法限制使用者,而且之前的代码已经这样做了,改动量非常之大。不过好在,现在自己用的框架是在 Requests Session 上封装了一层,操作 header 都是调用的统一的 update_headers 方法:

对 headers['Cookie'] 的操作拦截一下,变成对 cookies 的操作:

这样即不用改之前的调用方代码,也防止了后人掉坑。

 

参考资料

https://requests.readthedocs.io/en/master/user/advanced/#session-objects

https://stackoverflow.com/questions/2422922/python-urllib3-and-how-to-handle-cookie-support

https://urllib3.readthedocs.io/en/latest/reference/index.html#module-urllib3.poolmanager

https://urllib3.readthedocs.io/en/latest/reference/index.html#urllib3.connectionpool.HTTPConnectionPool.urlopen

https://docs.python.org/2/library/cookie.html

Filebeat核心配置详解

Filebeat简介

现在 ELK(Elasticsearch、Logstash 和 Kibana)日志分析系统非常火,但相关的介绍忽略了重要的一环:日志采集。虽然 Logstash 也能采集日志,但比较重、资源占用高,显然不适合线上和业务部署,所以一开始搞了个 logstash-forwarder 后来整合为 Filebeat。慢慢还发展成了一个 Beats 系列,支持采集各种各样的元数据。

Filebeat原理

说到实时查看日志,最常用得莫过于 tail -f 命令,基于此可以自己实现一个简单的日志采集工具,https://github.com/iyaozhen/filebeat.py/blob/master/filebeat.py#L237

但这太简陋了,无法保证不丢不重。我们看看 Filebeat 是怎么实现的,官方说明:https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-overview.html

简单来说 Filebeat 有两大部分,inputs 和 harvesters,inputs 负责找文件(类似 find 命令)和管理 harvesters,一个 harvester 则和一个文件一一对应,一行行读然后发送给 output(类似tail -f)。

当然还有很多细节问题,我们结合配置文件一一详解。

Log input配置详解

官方配置说明:https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-log.html

先看一个基本例子(下面所述基于7.x版本,6.x版本也基本适用)

inputs 可以配置多块(block),就是相同类型的放一块,这个也很好理解。paths 可以配置多个文件,文件路径和文件名都支持通配。

ignore_older 和 scan_frequency

这就有两个细节问题了,一是路径下的历史文件可能很多,比如配置了按天分割,显然旧文件我们一般是不需要的。二是扫描频率如何控制,通配设置复杂的话频繁扫文件也是很大的开销。

问题一则是通过 ignore_older 参数解决,意思就是多久前的旧文件就不管了。比如设置为 1h,表示文件时间在 1h 之前的日志都不会被 input 模块搜集,直到有新日志产生。

问题二则是通过 scan_frequency 参数控制,表示多久扫描一次是否有新文件产生。比如设置 10s(默认),一个新文件产生 10s 后会被发现,或者一个旧文件(上面 ignore_older)新产生了一行日志 10s 才发现这个文件。有人说我需要实时性,是不是这个值设置的越小越好,其实是错误的,前面我们介绍了 Filebeat 架构,input 模块只是负责发现新文件,新文件是相对已经被 harvester 获取的文件,第一次发现之后就已经在被 harvester 一行行实时读取了,所以这里基本上只影响日志切分时的实时性(这种场景下的短暂延迟是可以接受的)。

close_* 和 clean_*

那么被 harvester 获取的文件就一直拿着不放吗?文件重命名或者被删除后怎么办呢?这里重点介绍这两组配置。 Continue Reading...

现代化的PHP-写好注释

注释

有个段子:程序员最恨写注释和不写注释的人。个人认为注释主要作用是方便别人或者自己以后能快速理解这段代码逻辑和提升开发效率,这样要说的是如何使用注释来提升开发效率。

众所周知,PHP 是弱类型语言,变量的类型是可以变的,但在实际业务中,一个变量或者函数的返回值往往是确定的,确定的类型能提升我们的编码效率,也能把一些低级的错误(弱类型不代表无类型)扼杀在摇篮里。

PHP 主要通过类型声明来说明变量的类型,PHP7 开始允许更多的函数参数类型限定。比如下面这个例子,声明入参是 int 类型,但使用了 array 函数来处理,PhpStorm 能给出实时的提醒。

调用函数参数错误的话也有提示:

但 PHP 会有隐式类型转换,如上面传入浮点数的时候并没有提示错误,因为这也是合理的。不过 PHP 可以开启严格模式来检查此类错误。

PHP 内置的类型声明基本上够用了,但一般使用注释来实现更加丰富的功能。PHPDoc 是注释 PHP 代码的非正式标准,它有许多不同的标记可以使用。PhpStorm 能根据函数/类方法自动生成基本的标记:

基本标记 @param@return 也很好理解,参数和返回值,作用和 PHP 自带的类型声明差不多,主要用来限制调用方传参和使用返回值。除了这两个标记之外,还有很多其它比较好用的标记。

Continue Reading...

GitHub 研发链 travis-ci 和 codecov 介绍

经常混迹于 GitHub 的话就会发现很多项目都有一些徽章,出现最多的就数这两个了:

这些徽章都是可以点击的,第一个点进去是 https://www.travis-ci.com/,travis-ci 是一个 CI(Continuous integration,持续集成) 平台,主要提供集群编译、单测、集成测试的环境。.org 的服务对公有仓库免费,.com 面向私人、团队、公司的项目提供商业支持(收费)。使用起来非常简单,使用 Github 帐号登录进去,就能看见开始界面:

核心就是.travis.yml的文件配置,一开始可以根据自己的语言选择初始的配置文件:https://docs.travis-ci.com/user/customizing-the-build#Specifying-Runtime-Versions。我这边的项目使用的是 Python,初始配置是:

官方注释可以说非常详细,我就不画蛇添足做说明了,根据自己代码实际情况做调整即可:

配置好之后再 push 代码,就能在 travis-ci 页面上看见项目的构建、测试结果了:

点击图标就能生成我们需要的 MD 语法的代码了,粘贴进 README.MD 中就能显示了。

第二个徽章是 codecov.io(单测覆盖率统计平台),接入过程也很简单,也是不同语言选择不同的配置文件,codecov 可以无缝衔接 travis-ci,只需要在原来的配置文件上稍作修改即可,核心就是生成单测的结果文件。修改后的 .travis.yml

在原来的基础上多了 codecov nose 插件的下载和运行单测时多了--with-coverage等参数。最后还是再次 push 代码就能看见单测覆盖率报告了:

codecov 还有自己的配置文件:codecov.yml。用来实现一些定制化需求,比如说我需要排除一些模块,不进入覆盖率统计:

徽章生成代码的话在setting中可以找到:

除了上面介绍的这两个徽章,还可以通过 shields.io 平台生成一些其它的徽章,甚至可以自定义,比如 https://img.shields.io/badge/Python-2.7-brightgreen.svg 就可以生成一个表示 Python 版本的徽章,别人能看懂就行。

当然徽章不是重点,不是越多的越牛逼,重要的是规范整个研发流程。上面说的两个其实都是属于 CI(持续集成)中最具代表性的两个环节,算是入门了。关于 CI 是一个很大的话题了,这个有机会以后再说一下。

参考资料:

开源项目徽章集锦,https://segmentfault.com/a/1190000004278253

使用 Python nose 组织 HTTP 接口测试

现在前端 Web、移动端 APP 开发基本上是面向接口编程,后端各种 HTTP 接口已经提供好了,大家只要实现逻辑交互和展示就行。那么问题来了,这么多接口如何方便的进行测试呢?根据个人经验,我认为需要解决三个问题:1. HTTP 接口多种多样,测试程序如何统一?2. 测试程序如何规范组织?3. 接口间有上下文依赖,如何解决?

HTTP 接口多种多样,测试程序如何统一?

后端接口可能来自各个系统,GET/POST 协议的、遵循 RESTful 规范的,使用 session 认证、token 认证的,各式各样的接口都存在。但无论怎么变都无法脱离 HTTP 协议。因为组内的技术栈是 Python,这就很容易想到使用 Python 的 requests 库。首先我们使用requests.Session()会话对象,来进行会话保持和 Header、Cookie 等处理。这里我们可以简单封装一个 HttpSession 类,把一些常用操作和设置封装一下:

通过HttpSession()来获取一个requests session对象,后续的 HTTP 请求都通过它发起。requests 提供 get()、post() 等各种方法调用,但这会让测试代码显得不统一,这里我们直接调用底层的 request 方法,该方法几乎提供了发起一个 HTTP 请求需要的所有参数,非常强大。

这样每一个 HTTP 接口的测试都可以通过准备参数发起请求断言结果三板斧来解决。

测试程序如何规范组织?

前面我们已经解决了如何快捷的发起一个 HTTP 请求的问题,这让我们几行代码就可以测试一个接口的返回值。但你会发现新的问题又来了,各种脚本散乱在一堆,返回值解析各种中间变量,各种配置硬编码在代码中,测试结果全靠 print,这时 nose 框架就派上用场了。nose 是 Python 最流行的一个单测框架,提供测试 case 设置标签、测试 case 查找、强大的断言函数,格式化/可视化报告输出等功能。这样就可以像写单测一样写 HTTP 接口测试了。我们可以把一类接口的测试放在一个类里面,甚至可以把基础变量的定义放在基础测试类里面,其它测试类继承这个基类。

HttpTest基类只做了两个工作:1. 创建http会话对象;2. 读取配置文件到类变量config中。配置文件是一个很好的编程实践,这让我们测试程序和数据能够分离,可以通过调用不同的配置文件来测试不同环境的接口,让我们测试程序不光能做线下测试,还能做线上回归和监控,切换成本非常低。

我这里选择 yaml 语法来组织配置信息,yaml 语法风格类似 json,自带基础数据结构,但更加易于书写和阅读,非常适合做配置文件。通过-env=xxx指定配置文件路径(或者 nose.cfg 配置文件中指定),使用 ruamel.yaml 来解析 yaml,转换为 Python 中能直接操作的数据结构。

这一切都放在setUpClass方法中,在具体测试 case 运行之前就已经准备好这些工作了。 Continue Reading...

使用karma+mocha进行前端测试驱动开发(一)

之前有接触过一些使用 casperJs 做前端自动化测试和页面元素监控,效果还不错,这个后续有时间再介绍一下。但对前端代码层面的测试不是很了解,今天下班比较早,闲来无事,就看了下最近听说的 karma+mocha 前端测试框架,发现还是很有意思,收(刚)获(刚)颇(入)多(门)。目前来看 karma+mocha 非常适合做 TDD(测试驱动开发)。

测试驱动开发(英语:Test-driven development,缩写为 TDD)是一种软件开发过程中的应用方法,由极限编程中倡导,以其倡导先写测试程序,然后编码实现其功能得名。

TDD 提倡写代码之前先把单测写好,然后通过单测来验证代码是否正确。这就需要有一个单测框架(即 mocha),但这还不够,也不能每写完一次就运行一下单测代码,这也效率太低了吧,所以还需要一个框架(即 karma)来做这个事情。

这里先介绍一些 JS 单测框架 mocha(https://github.com/mochajs/mochatj 大神的作品,奈何大神觉得 Node 没搞头去搞 go 了)。安装还是比较简单,这里就不多说了。提醒一下,如果是在 Windows 下安装 Node 的话可能需要设置一下环境变量

实例:一个加法模块src/add.js的代码:

各个语言写单测都差不多,就是对预期结果的断言。上面代码对应的测试代码tests/add.test.js

测试脚本里面应该包括一个或多个describe块,每个describe块应该包括一个或多个it块。

describe块称为“测试套件”(test suite),表示一组相关的测试。它是一个函数,第一个参数是测试套件的名称(“加法函数的测试”),第二个参数是一个实际执行的函数。

it块称为“测试用例”(test case),表示一个单独的测试,是测试的最小单位。它也是一个函数,第一个参数是测试用例的名称(“1 加 1 应该等于 2”),第二个参数是一个实际执行的函数。

断言库有很多种,mocha 并不限制使用哪一种。上面代码引入的断言库是 chai,并且指定使用它的assert断言风格。因为这更接近其它语言的风格。

运行一下测试代码:

filehelper_1472143702070_9

大概流程就是这样,详细的可以查看官方文档。随便说一下,WebStorm 和 PhpStorm 原生支持 mocha,设置一下即可右键运行时直接调用 mocha 来运行当前 JS 单测文件:

20160826005459

20160826005634

20160826005739

单测已经写好了,怎么能让测试驱动我开发呢?这时候就需要 karma(https://github.com/karma-runner/karma)登场了。如 github 主页上所说,Karma 不是一个测试框架,也不是一个断言库,仅仅启动一个 http server,并通过你熟知的测试框架生成运行测试的HTML。Karma 支持的测试框架非常多,如前文介绍,我们这里选择的是 mocha 测试框架和 chai 断言库。

首先安装 karma,然后使用karma init my.conf.js命令生成配置文件。生成文件的过程是交互式的,很友好,注意选择测试框架是 mocha。选错了也没关系,配置文件之后可以手动编辑,大概长这样:

比较重要的几个参数:

  • frameworks:我们这里需要 mocha 和 chai。框架必须预先通过 npm install karma-xxx --save-dev 命令安装好,支持的框架详见:https://www.npmjs.com/browse/keyword/karma-adapter
  • files:可以配置通配符把源代码和测试代码加载进来。
  • browsers:需要启动的浏览器
  • autoWatch:观察文件是否变动,如有变动则重新运行单测。

最后使用命令karma start my.conf.js运行即可。但这里我一直失败,遇到如下这些错误:

这是因为上文的代码使用的是node的require()语法,karma是在浏览器端运行的,当然不支持了。如果你的源代码使用的是 AMD、CMD 加载器,测试代码也要使用 requirejs 等框架加载源代码模块。这里我们将源代码和测试代码稍微改造一下就行了:

成功运行:

20160826014133

karma 可以启动不同的浏览器,所以还可以做兼容性测试。

我修改一下源代码,karma 能自动监听到文件变动,然后显示单测结果,这样我就能实时知道代码是否有问题。

karma

当然这只是 karma 的一个功能,还有很多实用功能等待后续学习。

参考资料:

测试框架 Mocha 实例教程,https://www.ruanyifeng.com/blog/2015/12/a-mocha-tutorial-of-examples.html

[JavaScript] Test Suit 4 - Test Runner - Karma,https://karma-runner.github.io/latest/index.html

典型的用户注册页面短信验证逻辑漏洞

用户注册是一个网站基本的功能,做过 web 开发的基本上都写过这个功能,但很多漏洞都出在这个页面上面。这里先不讨论密码加密存储,传输安全等问题,就说说注册页面的功能逻辑。

2016-05-22_000624

如上图的新浪微博注册页面,一般的注册页面都需要填写账号、密码等信息,为了防止恶意注册,都还有一个验证码,这几乎是一个注册页面的标配了。现在有些注册页面会多一个手机验证,防止恶意注册的同时也变相完成了实名制的红头文件要求,但有时候问题就出在这里。

2016-05-18_020524

上图这个注册页面,中规中矩,看似没什么问题,填写一些信息后点击下一步:

2016-05-18_020915

很常见的操作,POST 请求将信息带到下一个页面(校验了图形验证码),跳过来的同时已经给手机发了短信验证码,到目前为止没什么问题,用户体验还不错。不过发现页面上还有一个重新发送的按钮,点击一下发现直接调用 /sendRegMsg 接口发送了短信,接口只接收一个手机号参数,无其它参数。这里就是第一个漏洞:短信发送接口无权限验证,可被恶意调用造成经济损失,还可被利用于“短信炸弹”,而且这家厂商本身就是提供短信验证码服务的,估计“短信炸弹”效果更改。要解决这个漏洞也很简单,加个验证码就行了,但这里可能又会有一个坑(后面细说)。实际短信验证码为 4 位,提交企业名称等信息时也没有图形验证码校验:

2016-05-18_021422

那就好办了,直接跑个小脚本暴力提交(最多9999次)即可:

2016-05-18_024823

这里就是第二个漏洞了,任意手机号注册(一大波薅羊毛党将要来袭):

2016-05-18_024610

这两个漏洞都是很好修复的,影响也不大,但若安全意识薄弱,逻辑没有理清楚会造成修复不彻底。比如在短信重新发送操作那里加了一个图形验证码,发送短信和提交时都会做校验,但若你调用一次短信发送接口后图形验证码没有重置,我就可以拿着这一个正确的图形验证码一直调用发送短信接口(重放攻击)也能达到恶意调用和“短信炸弹”的目的,提交信息时也可以用这一个的正确图形验证码暴力提交。还有的为了限制短信发送频率,点击发送短信后将发送按钮设置为 disabled="disabled",然后设置一个定时器 60s 后恢复,这完全也是自己骗自己。

一种比较好的做法是每发一次短信图形验证码都重置,短信验证码填写失败一定次数后重置校验 session,后面任何输入都返回错误。

其实这个漏洞很鸡肋也很低级,但目前这种逻辑漏洞已经成为主要的问题,看似低级,但很难避免,往往影响还很大。而且我们可以看到图形验证码在整个流程中扮演了很重要的角色,但你的图形验证码真的安全吗?答案是否定的,百度贴吧和 12306 “变态”的验证码都是几天内就被破解了,甚至还有人工打码平台,可谓是道高一尺魔高一丈。安全,还是仍重道远呀。

推荐阅读:

黑产揭秘:“打码平台”那点事儿 https://www.cnblogs.com/alisecurity/p/6110143.html

参考资料:

无(不要问为什么知道这类漏洞)

kanqiu_26461760_2144148040__20160126154003

本 Blog 不支持评论,如有疑问或建议请联系我,以完善内容,期望帮助到更多的同学