标签：安全

共 18 篇相关文章

IT 累计浏览 2,737

Android APK 签名文件MANIFEST.MF、CERT.SF、CERT.RSA分析

这篇讲的是Android APK签名中三个关键文件：MANIFEST.MF、CERT.SF和CERT.RSA的内部结构和作用。作者从一个已签名的APK入手，逐步解剖了这三个文件如何构成一个层层校验的“信任链”。核心机制是“三明治”式的校验：MANIFEST.MF首先记录了APK内所有文件的SHA-1哈希值，确保每个资源文件的完整性；接着，CERT.SF文件不仅保存了MANIFEST.MF本身的哈希值，还对MANIFEST.MF中的每一项描述再次进行SHA-1计算并存储，这相当于对“清单的清单”进行了二次确认。最后，CERT.RSA文件则包含了用于验证上述所有哈希值的公钥和签名者证书信息，完成了整个数字签名的闭环。文章不仅展示了每个文件的具体内容，还通过手动计算和使用OpenSSL工具生成密钥、提取证书等方式进行了实战验证，并引用了Android源码佐证。整个分析过程清晰地揭示了Android签名机制如何通过这种“文件哈希 -> 清单哈希 -> 对清单的签名”的三重保障，来确保应用的完整性与来源可信度。

IT 累计浏览 2,081

Android安全–Dex文件格式详解

这篇讲的是 Android 系统里 Dex 文件格式的深度解析。作者从一个简单的 Java 程序生成 Dex 文件开始，聚焦分析了文件头这个核心区域的内部构造。文章详细解读了魔数、校验码和 SHA-1 等关键字段。特别是为了确保文件安全，系统设计了双重校验机制：先用 Adler32 快速筛查文件是否损坏，再用 SHA-1 进行高精度的完整性验证。这种分层的设计思路既高效又可靠。此外，文章还剖析了文件头中字符串索引的存储方式。作者指出，Dex 文件使用了 uleb128 变长编码来表示字符串长度，这种精巧的编码能在绝大多数情况下节省空间，是针对移动端场景的务实优化。通过对这些底层细节的拆解，文章揭示了 Dex 文件如何兼顾执行效率与安全性。理解这些格式规范，是深入进行 Android 应用安全分析和性能调优的基础。

IT 累计浏览 1,464

iOS安全—dumpdecrypted APP砸壳

这篇讲的是iOS应用逆向工程中一个关键步骤：如何给从App Store下载的加密应用“砸壳”。作者从dumpdecrypted这个工具出发，详细拆解了整个解密流程。文章首先点明背景：商店下载的应用都带有加密壳，阻碍了class-dump或IDA这类静态分析工具的使用。核心方案分三步走：首先在本地下载并编译dumpdecrypted源码，生成一个dylib动态库；接着，通过Cycript等工具定位到目标应用的沙盒目录——因为只有沙盒内才有读写权限；最后，将生成的dylib上传至该目录并注入，启动应用即可完成解密。其巧妙之处在于原理的简洁：通过DYLD_INSERT_LIBRARIES环境变量，强制让App加载这个自定义的dylib。动态库在初始化时便会执行dump操作，从而在运行时将解密后的二进制数据导出。整个过程清晰地展示了如何利用系统机制与沙盒环境来实现对加密应用的动态脱壳，为后续的深度分析扫清了障碍。

IT 累计浏览 6,642

如何设计用户登录

这篇讲的是如何设计一个灵活可扩展的用户登录系统。作者从最常见的用户名+密码登录入手，指出当需要集成微博、QQ等第三方登录时，传统做法——在Users表中不断新增列来存储OAuth信息——会导致表结构日益臃肿，维护成本很高。核心解决方案是将“用户资料”与“认证信息”进行分离。具体来说，将Users表精简为只存放用户个人资料（Profile）；而将登录认证（Authentication）过程独立出来。本地密码登录维护一个LocalAuth表，而微博、QQ等第三方OAuth登录则统一到一个OAuth表中，通过`oauth_name`字段区分不同来源。这种设计的好处显而易见：添加新的登录方式（如SAML）只需新增记录或表，无需改动用户主表；一个用户可以绑定多种登录方式；同时，由于Users表不再存放口令等敏感数据，系统安全性也得到了提升。

IT 累计浏览 3,394

第三方支付为什么会兴起

这篇文章从作者多年的外贸经验切入，探讨了一个有趣现象：为何在国际贸易中早已成熟的银行担保模式（如信用证），到了国内电子商务领域，却被第三方支付全面取代。作者指出，支付宝的担保交易原理与信用证如出一辙，都是为了解决远程交易中的信任问题。但奇怪的是，银行并未将这套成功的经验复制到国内网购市场，这种“不闻不问”的态度，为第三方支付的崛起留下了巨大的市场空白。文章还对比了信用卡的历史——它同样由第三方机构首创，后因银行受地域经营限制，才催生出跨行合作的卡组织来反超。核心观点在于，银行因过往业务过于舒适，低估了互联网支付的战略意义，未能及时行动。等到第三方支付从工具演化到金融平台时，格局已定。文章最后抛出一个开放性问题：历史上第三方支付曾颠覆信用卡旧模式，未来它是否会进一步侵蚀银行信用证业务？这不仅是商业策略的复盘，也揭示了技术浪潮中，巨头的疏忽如何让机遇溜走。

IT 累计浏览 3,650

SSH免密码认证进阶使用

这篇文章深入探讨了SSH免密码认证的进阶技巧，超越了基本的密钥生成与配置。作者从实际运维中遇到的多服务器、多密钥管理痛点出发，详细演示了如何利用ssh-agent高效管理不同服务器的私钥，并通过Agent Forwarding安全地跳转跳板机，避免将密钥暴露到中间节点。文中特别对比了不同加密算法（如Ed25519与RSA）在安全性与性能上的差异，建议了具体的选型策略。对于需要频繁切换身份的场景，文章讲解了基于Host指令为不同服务配置独立密钥对的实用方法。最后，作者结合一个自动化部署脚本的实例，展示了如何将这些进阶配置融入CI/CD流程，显著提升了运维工作的安全与效率。

IT 累计浏览 3,043

QQ 用户关系的迁移

这篇讲的是QQ后端架构中，一个核心但不太为人知的“好友关系”存储层迁移过程。文章从现实问题出发：承载了数亿用户的MySQL分库分表架构，逐渐在扩展性、运维复杂度和存储成本上遇到了瓶颈。作者详细拆解了将这套“关系链”从MySQL迁移到自研高性能TDE存储引擎的全过程。核心方案并非简单的替换，而是设计了一套复杂而精巧的“双写+异步校验”迁移机制，确保了亿万级用户关系数据在迁移过程中的绝对一致与业务无感。文章亮点在于对迁移细节的深入，比如如何设计新老数据的并行读写路径，如何处理迁移中遇到的海量数据校验问题，以及如何通过数据冗余和巧妙的索引设计，最终将单条记录的存储成本大幅降低。这次“心脏搭桥”手术完成后，不仅存储成本下降约50%，系统整体资源占用也显著降低，为后续的业务迭代打下了更坚实的基础。

IT 累计浏览 2,934

递归字符转义

这篇分享的是ecshop电商平台源码中一个用于字符转义的递归函数。作者从实际代码出发，拆解了这个函数如何解决一个常见但容易被忽略的问题：当数据以复杂嵌套数组或对象的形式传入时，如何确保内部所有字符串值都被统一、安全地转义处理。函数的巧妙之处在于其递归设计。它并非简单地遍历一层键值对，而是能够深入检测每个值的类型——如果是字符串则执行转义操作；如果是数组或对象，则自动将自身作为工具递归调用，从而“钻入”数据结构的每一层。这避免了开发者手动编写多层循环来处理不规则数据的麻烦，保证了无论数据结构嵌套多深，转义都能彻底执行。在安全处理用户提交的数据、防止SQL注入或XSS攻击的场景下，这种通用性强的递归方案显得尤为实用。作者通过分享这个细节，展示了如何用递归思维优雅地解决实际工程中的防御性编程需求。

IT 累计浏览 8,970

腾讯php程序员面试题目答案

这篇文章讲的是对腾讯经典PHP面试题——“请设计一个函数，对一系列字符串进行排序”——的深入探讨。作者在“鸦片师兄”已有解答的基础上，并未止步，而是提出了一种新的优化思路。其核心创新在于引入了“令牌算法”的概念来改进排序过程。传统的字符串排序可能在某些场景下效率有待提升，而作者的解法通过令牌机制，更高效地管理了字符串之间的比较与交换操作，从而优化了整体性能。具体来说，这种优化体现在对排序逻辑的精炼上，尤其是在处理大规模或特定规则的数据集时，能够减少不必要的计算开销。文章不仅分享了代码实现，更重要的是展示了解题思维的演进过程——如何从一个现有方案出发，通过引入新的算法思想来达到性能提升的目的。对于PHP开发者而言，这不仅是一个面试题的参考答案，更是一次关于算法优化和思维拓展的实践教学。它启发我们，在面对已知解决方案时，依然可以寻找更优解，而令牌等控制思想在很多并发或资源管理场景中都能找到用武之地。

IT 累计浏览 3,172

在编译php-fpm0.6的时候需要注意的一些问题

这篇讲的是PHP-FPM 0.6版本编译时容易踩的坑。作者指出，虽然php-fpm 0.6早已发布，并且在应对如fix_pathinfo这类漏洞时比0.5系列更有优势，但不少开发者可能仍停留在旧版本。文章从实际编译经验出发，提醒大家升级到0.6时需要留意的特定问题。具体来说，编译过程中可能会遇到配置参数的变化、依赖库版本不匹配，或是与现有PHP扩展的兼容性问题。作者通过梳理这些常见的“坑点”，帮助读者提前规避，确保平滑升级。对于仍在使用PHP-FPM 0.5，或计划尝试新版本的运维和开发人员来说，这些细节经验可以避免不必要的排错时间。

IT 累计浏览 3,106

php的filter扩展小技巧

这篇讲的是，面对“永远不要相信用户输入”这条web安全铁律，如何用好PHP内置的filter扩展来高效实现数据过滤与验证。作者从新人老手混搭的小团队容易忽视输入验证，导致SQL注入、XSS攻击等漏洞频发的现状出发，引出了PHP filter扩展这个强大的“守门员”。文章没有停留在泛泛而谈安全重要性，而是直接切入具体操作，详细讲解了filter_var()和filter_input()等函数的使用小技巧。比如，如何用FILTER_VALIDATE_EMAIL快速验证邮箱格式，用FILTER_SANITIZE_STRING过滤危险的HTML标签，或者结合FILTER_FLAG_NO_ENCODE_QUOTES等标志位进行更精细的控制。这些技巧的巧妙之处在于，它们都是PHP内置函数，无需额外安装扩展，却能以声明式的方式，让原本繁琐的数据清理和验证工作变得清晰、安全且易于维护。文章通过实际场景的示范，把安全规则转化成了几行可靠、简洁的代码，对于快速搭建安全的数据处理管道很有帮助。

IT 累计浏览 2,617

深入理解SET NAMES和mysql(i)_set_charset的区别

这篇讲的是在PHP操作MySQL时，看似效果相近的SET NAMES和mysqli_set_charset函数，其实存在一个关乎安全的重要差异。作者从一次PHP安全编程培训切入，指出许多开发者混用这两个命令，但它们在协议层面的工作机制完全不同。SET NAMES仅仅是在MySQL服务器端设置字符集，它告诉服务器“我接下来发的数据是这个编码”，但并不会改变PHP客户端本身的编码认知。而mysqli_set_charset则不同，它通过专用协议命令，同时修改了客户端和服务器端的字符集。关键差异在于：只有使用mysqli_set_charset后，PHP的mysql_real_escape_string函数才能基于正确的客户端字符集进行转义。如果仅用SET NAMES，转义函数可能因编码理解错误而失效，这为SQL注入攻击留下了潜在漏洞。文章清晰地指出了各自的使用场景：SET NAMES更适合用于纯数据库层面的字符集沟通，而涉及客户端与数据交互的编码设置，务必使用mysqli_set_charset以确保安全。这个区分是编写健壮PHP数据库代码的基础。

IT 累计浏览 1,581

通过PHP的Wrapper无缝迁移原有项目到新服务

这篇讲的是在一套特定约束下，如何巧妙地完成项目迁移。背景是，出于性能和安全考虑，平台禁用了直接的本地文件读写与对外网络抓取，但通过独立的微服务提供了对应能力，且接口有所不同。这意味着，原有代码中大量基于文件操作和数据抓取的逻辑，都需要重写以适配新服务，改造成本和风险都很高。文章提出的核心方案，是利用 PHP 语言自身的流包装器（Stream Wrapper）机制。作者没有选择硬改业务代码，而是通过 `stream_wrapper_register` 函数注册了一个自定义的协议处理程序。这样，当原有代码执行 `file_get_contents('/some/path')` 时，系统会自动将调用拦截，透明地转换成对后端新服务接口的请求。对于网络抓取，也是同理，将 `curl` 调用层通过 Wrapper 进行封装和转发。这种方案的巧妙之处在于，它将迁移的复杂度从成百上千处业务代码的修改，集中到了对 Wrapper 类本身逻辑的实现与调试上。原有项目的基本代码结构和调用方式得以保持，实现了近乎“无缝”的迁移效果。对于面临类似基础设施变更或服务化改造的团队，这种利用语言特性构建适配层的思路，提供了一种低侵入、高内聚的解决方案。

IT 累计浏览 1,720

PHP magic_quotes_gpc的详细使用方法

这篇深入讲解了PHP中magic_quotes_gpc的具体工作机制与应用。文章指出，这个“魔术引号”特性并非对所有输入都生效，而是有一个明确的触发范围：仅当数据通过$_GET、$_POST或$_COOKIE这三个超全局数组传入PHP脚本时，它才会对数据中的单引号、双引号、反斜杠和NULL字符自动进行转义处理。这个机制在当时被设计为一种防御SQL注入等攻击的简便手段。文章还强调了该功能的可控性。开发者可以通过php.ini配置文件中的`magic_quotes_gpc`指令来开启或关闭它（默认开启）。然而，在实际的编码实践中，更推荐在运行时使用`get_magic_quotes_gpc()`函数来动态检测此功能的状态，并据此进行相应的处理逻辑调整，以确保代码的健壮性与可移植性。虽然magic_quotes_gpc在现代PHP版本中已被移除，但理解其设计逻辑与使用局限，对于掌握PHP输入处理机制的演变、编写安全兼容的代码具有重要的参考价值。

IT 累计浏览 3,281

对目前网银提现系统的一个小疑问

这篇讲的是作者在设计提现系统时，如何通过拆解现有支付产品来寻找设计思路。他对比了支付宝与百付宝（百度支付）在“提现信息设置”这一具体模块上的交互与逻辑设计，发现两者存在一些值得玩味的差异。作者并非简单罗列功能，而是带着问题去观察：例如，在设置提现银行卡时，两家产品的流程步骤、信息分组方式各有不同，这背后可能体现了它们对用户操作习惯、风险控制的不同侧重。文章将这些观察提炼成了具体的设计疑问，抛给了读者。对于正在从事支付或金融产品设计的同行来说，这种从现有产品出发、细抠模块差异的思考方式很有参考价值。它提醒我们，成熟的设计往往暗藏取舍，值得拆解和辩论，而不只是照搬。

IT 累计浏览 6,173

13 Linux的致命命令

这篇讲的是Linux系统中那些看似平常却可能瞬间毁掉整个系统的危险命令。作者从实际运维中的惨痛教训出发，列举了13个足以清除主目录、根目录甚至整个磁盘的“致命操作”，比如危险的rm -rf组合与不加思索的通配符扩展。文章没有停留在单纯罗列命令，而是剖析了每条命令生效的底层原理：为何某些删除操作能跳过确认、通配符在特定环境下如何意外匹配到系统文件，以及为什么简单的sudo也无法阻止某些破坏。这些细节揭示了Linux文件权限机制中容易被忽略的陷阱，比如通配符在shell展开时可能匹配到隐藏的系统路径。对于系统管理员和开发者来说，这篇文章的价值不在于禁用这些命令，而是理解它们为何危险——只有看清破坏力的根源，才能在编写脚本或操作高危目录时建立起真正的防护意识。

IT 累计浏览 2,803

客户端应该去计算什么？

这篇讲的是客户端与服务端计算任务分配的艺术。作者从一个实际矛盾出发：现代客户端设备能力日益增强，将更多计算任务移至客户端，看似是分摊服务器压力、减少网络交互的利器。然而，文章没有止步于此，而是深入剖析了这种迁移背后的权衡。性能是首要考量，客户端可使用的资源与运行环境（比如为了兼容性而受限的 JavaScript 子集）可能导致其计算速度远慢于服务器。更关键的是安全问题，文章强调了“不信任任何外部数据”这一安全基石，当核心逻辑暴露在客户端时，如何保障业务逻辑与数据的安全就成了一道必答题。这篇文章的价值在于，它没有给出一个简单的“是”或“否”的答案，而是提供了一套思考框架，帮助开发者根据具体业务场景——对性能的容忍度、安全要求的级别——来做出明智的取舍。它促使我们重新审视那些看似“理所当然”的前端优化决策。

IT 累计浏览 3,006

账号密码包含反斜线时怎么办

这篇讲的是当用户在系统登录时，因账号密码中包含反斜线（\）而遭遇失败或异常的情况。问题的根源在于反斜线在许多技术场景中是一个关键的“转义字符”。它本身不具备字面意义，而是用来改变后续字符的含义，例如在编程字符串或正则表达式里。因此，如果直接在密码字段里输入一个反斜线，系统很可能无法正确识别，而是试图将其与下一个字符组合起来解析，导致实际提交的密码与存储的密码不一致，从而引发登录失败。文章针对这个看似细微但极易踩中的“坑”给出了具体的解决方案。核心思路是：用户在输入包含反斜线的密码时，需要使用双反斜线（\\）来进行转义，以确保系统能将其识别为一个真实的、字面意义上的反斜线字符。作者不仅点明了问题的技术原理，还给出了可操作的步骤，让遇到此问题的开发者能立刻定位并解决问题。对于任何需要处理用户输入（尤其是涉及安全凭证）的开发者来说，了解这种特殊字符的转义规则，是避免线上出现莫名其妙故障的基本功。