上周跑模型的间隙，看到一个关于 Python Pickle 反序列化的 CTF 题，和以往见到的不太一样，感觉很有意思，遂打算研究一下。
我们知道，当我们控制了如 `pickle.loads`等序列化数据的输入接口时，我们可以通过构造恶意的 Payload 来达到任意代码执行的效果。这是因为， `pickle` 库在反序列化(unpickling)的过程中，默认会导入 Payload 中找到的任意类或者函数对象。所以，Python 的开发者也一直警告大家，不要轻易用 `pickle` 来反序列化没有经过数据清洗的输入数据。同时，还推荐开发者通过实现自己的 `Unpickler`，来限制反序列化过程中能够 import 的类或函数，参考：https://docs.python.org/3.7/library/pickle.html#restricting-globals 。
由一个简单的问题，引发了这么一连串的代码分析，Python设计者也确实煞费苦心。不过研究技术，还是要有刨根问底的精神，把原理弄清楚，才能做好开发。刚刚不久前才开始用Python写点小程序，没有怎么仔细研究过，然后就遇到了一个很有趣的问题。
首先说明一下代码检查的重要性,python是一门静态语言,有很多检查工具(pylint、flake8等)都可以很好的检查代码. 平时我们大多数都是以插件的形式集成到编辑器(如Sublime、Visual Studio Code等).
Django是Python世界最有影响力的web框架。DjangoUeditor是一款可以在Django应用中集成百度Ueditor HTML编辑器的插件（Ueditor HTML编辑器是百度开源的在线HTML编辑器）。DjangoUeditor插件上存在一个漏洞，可以导致任意文件上传。
标题: MISC系列(43)–用GDB排查Python程序故障
创建: 2015-09-21 16:40
更新:
某Team在用Python开发一些代码，涉及子进程以及设法消除僵尸进程的需求。实践中他们碰上Python程序非预期退出的现象。最初他们决定用GDB调试Python解释器，查看exit()的源头。我听了之后，觉得这个问题应该用别的调试思路。帮他们排查这次程序故障时，除去原始问题，还衍生了其他问题。
用Python开发的代码，有些时候会出现一些故障，这些故障很难从Python级调试中排查出原因。此时，需要对Python解释器进行C级调试，以排查更底层的原因。本文以定位Python built-in函数的源码实现为例，展示这种C级调试的片段。