Java反序列化漏洞被忽略的大规模杀伤利用
这篇讲的是Java反序列化漏洞被大家热议时，一个关键攻击面却被普遍忽略了。作者指出，焦点大多集中在Web中间件上，但实际上，像RMI这类在企业级Java CS架构中广泛使用的通信协议，其传输过程完全基于序列化，是漏洞大规模利用的“原罪”。 文章核心观点在于，攻击者只需找到开放的RMI服务端口（默认1099），配合Apache Commons Collections等常用库，就能轻易构造攻击载荷实现远程代码执行。作者批评了许多修复建议只是“治标不治本”，并特别点明了原始研究中关于RMI利用的部分被众多安全人员忽视的现象。 文中不仅分析了原理，还对比了通用利用工具（如ysoserial）在获取回显交互时的不足，并展示了作者为解决此问题而编写的、针对RMI的具体实现代码。这提醒安全研究者，漏洞的实际影响面往往比最初曝光的更广，在企业内网的分布式服务中，这类风险可能更为隐蔽和普遍。
数据防泄漏DLP技术深度剖析
这篇文章从企业数据保护的演进出发，剖析了数据防泄漏（DLP）技术从粗放式“全加密”管理，向智能化、精细化管控转变的历程。作者指出，DLP的核心在于“内容识别”，以此为基础构建对结构化与非结构化数据的区分防护能力。 文章重点拆解了DLP的基础检测技术（正则、关键字、文档属性）与高级检测技术（EDM、IDM、SVM）的关键差异。例如，精确数据比对（EDM）适用于保护数据库中的客户信息，可通过多字段组合精准触发策略；而文档指纹（IDM）与支持向量机（SVM）则分别通过文件特征学习和语义分类，应对复杂文档与代码的防护。此外，文章还阐述了文件级、网络级、磁盘级动态加密技术的实现原理与适用场景。 在产品形态上，文章梳理了DLP从早期“设备强管控”的囚笼型、聚焦文档加密的枷锁型，到行为审计的监察型，再到当前具备内容感知能力的智慧型产品的演变路径。最后提到，在国产化浪潮下，国内DLP产品正从萌芽走向成熟，市场潜力与挑战并存。
REST API 安全设计指南
这篇指南从REST API安全缺失的现状出发，系统梳理了其安全设计的核心环节。作者首先点明REST虽架构简洁，但安全特性需开发者自行实现，因此将HTTPS作为一切安全的基石。 摘要的主体围绕关键安全机制展开。它对比了从简易到严谨的认证方案：HTTP Basic因Base64编码近似明文，务必结合SSL；API Key方案通过签名与时间戳能防篡改与重放攻击；而OAuth与JWT则提供了更标准化、更安全的现代选择。在授权部分，文章用代码示例说明了基于角色与正则的权限控制如何实现，并强调需在业务逻辑中防范平行越权。 此外，摘要提炼了数项实用防御措施：对URL参数与请求格式进行前置过滤、关键功能强制加密传输、利用内存数据库实现请求速率限制，以及通过结构化错误码与多状态码提升API的健壮性与安全性。最后，诸如对敏感ID进行不透明化处理等细节，共同构成了一套从传输、认证到逻辑处理的完整安全实践框架。
移动APP安全测试要点
这篇文章由绿盟科技移动APP安全测试专家侯绍岗、杨乔国撰写，以一次真实的Android APP安全测试为案例，系统拆解了移动应用可能面临的威胁与关键检测点。 作者从运营商APP自主开发越来越多但可能绕过应用市场审核这一现状切入，提出了从评估思路到自动化检测的完整框架。文章的核心在于具体的安全检测要点：比如，`allowBackup`属性设置不当可能导致用户数据被导出；WebView未限制方法调用，会为JavaScript攻击设备敞开大门；登录等关键数据若使用HTTP明文传输，则易被网络监听截获；甚至在注册环节，若服务器未验证提交的手机号与下发验证码的手机号是否一致，也可能被利用注册任意账号。 文章不仅给出了明确的整改建议（如将`allowBackup`设为`false`、对敏感数据加密传输），还深入探讨了检测中发现的争议点。例如，关于“关键数据明文传输”是否算漏洞，作者对比了金融、社交等不同平台的安全要求差异；而针对“登录界面可被钓鱼劫持”的风险，文章通过Android启动Activity机制的原理图解，演示了恶意程序如何抢先推送伪装界面，并对比了有无防劫持提示的APP表现，直观说明了该风险的实际危害与防御价值。 这篇技术复盘不仅罗列了漏洞清单，更通过原理分析、情景演示和行业讨论，为安全从业者提供了从识别、评估到整改的实践思路。
IOS安全–浅谈关于IOS加固的几种方法
这篇讲的是iOS平台加固方法的梳理与对比。作者开篇就点明了iOS系统在未越狱时的相对安全性，但同时也指出，针对逆向分析与破解的加固需求并未消失。 文章重点对比了市面上几款iOS加固产品的早期形态：从被作者认为是“噱头”的爱加密IOS加密，到使用起来需要替换编译器的Safengine工具，再到体验相对较好、考虑更周全的白盒加密方案。通过这些产品演进，带出了当前iOS加固的主流技术方向。 核心内容围绕四种具体方法展开：一是字符串加密，防止明文信息被静态分析直接获取；二是类名与方法名混淆，让通过class-dump得到的接口难以被理解；三是基于Clang编译器IR层的代码混淆，增加反编译后的逻辑分析难度；四是集成安全SDK，提供反调试、注入检测、越狱检测等运行时防护能力。文章不仅指出了问题现状，也给出了部分方法的开源实现参考。 作者以亲身实践的角度，串联起了iOS加固从工具产品到具体技术实现的全景，为关注移动端安全的开发者提供了清晰的入门图景。
iOS安全系列之二：HTTPS进阶
这篇讲的是在iOS开发中如何让HTTPS连接更安全，作者从实际遇到的HTTPS问题出发，深入剖析了中间人攻击的几种常见形式。文章首先模拟了最简单的钓鱼式攻击，通过Charles代理工具详细演示了攻击者如何利用伪造证书窃取HTTPS流量，直观暴露了许多App仅依赖系统默认校验的安全隐患。 在此基础上，作者对比了SSL剥离等更具隐蔽性的攻击手段，并针对性地指出了防范关键：不仅要依赖系统校验，App内部更应对服务器证书进行本地的、硬编码的对比校验。文中还延伸讨论了iOS 9引入的App Transport Security（ATS）特性，以及如何使用Wireshark调试SSL/TLS通信，将理论与开发实践紧密结合。 对于希望加固应用网络安全的开发者而言，文章从攻击原理到防御代码都提供了具体思路，特别是关于WebView中易忽略的URL协议校验等细节，具有很强的实操参考价值。
iOS安全系列之一：HTTPS
这篇讲的是HTTPS，但不是泛泛而谈。作者从iOS开发者普遍对安全不够重视的现状出发，指出即便是未越狱设备，网络安全依然是不可回避的课题。文章的核心，是厘清HTTPS并非什么新协议，其本质只是在HTTP之下增加了一层SSL/TLS加密。 最硬核的部分在于对SSL/TLS原理的拆解：它通过四次握手交换三个随机数来生成安全的“对话密钥”，并依赖数字证书体系（PKI）进行身份验证。文章用清晰的逻辑讲透了证书的签发与验证流程——接收端如何通过哈希对比和递归验证，最终追溯到操作系统内置的根CA。这解释了“为什么信任链的起点如此重要”。 在实现层面，文章没停留在理论。它具体展示了如何在iOS的NSURLConnection中处理证书验证回调，利用Security Framework的API完成Trust Object的评估。无论是使用系统默认验证，还是为自建证书等高安全场景进行更严格的本地匹配校验，都给出了可落地的代码思路。对于想用AFNetworking简化流程的开发者，也有明确的指引。 从概念辨析到原理图解，再到代码级实践，这篇文章提供了一条清晰的路径，帮助开发者完成从HTTP到HTTPS的安全升级。
Android安全–DexClassLoader动态加载分析
这篇讲的是DexClassLoader在Android动态加载中的具体实现机制。作者从DexClassLoader的构造函数切入，像侦探一样，一步步追踪代码执行流程。 他沿着构造函数进入父类BaseDexClassLoader，再到关键的DexPathList，最终锁定了加载dex文件的核心函数`loadDexFile`与`openDexFile`。这条路径清晰展示了参数如何被解析与传递。 最巧妙的部分在于，作者将分析延伸到了native层。在`openDexFileNative`函数中，系统会根据文件后缀，分别调用`dvmRawDexFileOpen`处理dex文件或`dvmJarFileOpen`处理jar包，最终返回一个统一的`DexOrJar`结构。这揭示了Android如何将不同格式的代码包归一化处理，巧妙地衔接了Java与Native层的实现。
说说 XcodeGhost 这个事
这篇文章围绕曾经引起广泛关注的“XcodeGhost”事件展开。作者并非单纯复述事件经过，而是从一个技术观察者的视角，深入剖析了这场安全风波背后的技术逻辑与行业生态。 文章指出，被植入木马的Xcode确实导致了大量国产App被污染，但其实际危害程度需要理性评估。作者核心观点在于，iOS系统自身的安全设计（例如iCloud密码的高优先级保护、沙盒机制）构筑了多道防线，有效限制了恶意代码所能造成的最坏后果。他详细解释了为何直接窃取iCloud密码极其困难，并指出了用户可识别的钓鱼特征，如对话框反常地要求输入完整的Apple ID。 更重要的是，作者将此事与国内开发者普遍集成不明第三方SDK的风气进行了对比，认为后者对App信任链的破坏远超XcodeGhost。他借此批评了行业安全意识的薄弱，并呼吁用户（尤其是国产安卓用户）加强基本防护，如开启二步验证、谨慎对待系统弹窗。文章最后回归到技术本质，强调了操作系统层面安全机制的关键作用，为读者提供了在恐慌情绪之外更为冷静和深入的安全思考。
Android安全–检测是否为Android模拟器
这篇讲的是如何在应用层面检测 Android 模拟器环境。作者从应用安全的角度出发，指出在某些场景下（如反欺诈、版权保护）需要区分真机与模拟器，随后提供了一套完整的检测代码实现。 文章的核心思路是综合利用模拟器环境在多个维度留下的特征。代码中演示了几个典型的检查点：首先扫描系统中是否存在已知的 QEMU 虚拟管道文件（如 `/dev/socket/qemud`）或特定的驱动程序标识（如 `goldfish`），这些是 Android 模拟器的标准配置产物；其次，通过读取 `/proc/cpuinfo` 文件检查 CPU 信息，或查询电池状态（如电量始终为满且温度恒定），因为模拟器硬件信息往往显得“完美”且缺乏真实设备的动态变化。 这些检测手段组合起来，能形成一个相对可靠的模拟器判断模型。文章没有停留在理论层面，而是直接给出了可集成的 Java 代码片段，对于需要快速落地检测功能的开发者来说，提供了一个开箱即用的参考方案。
Android libcutils库中整数溢出导致的堆破坏漏洞的发现与利用
文章从研究Android图形子系统时发现的一个整数溢出漏洞讲起，这个漏洞存在于libcutils库的native_handle_create函数中。作者龚广(@oldfresher)揭示了，当传入精心构造的numFds和numInts参数时，会导致堆内存分配大小计算溢出，进而引发堆破坏。具体来说，这个漏洞可通过Android图形系统的Binder接口（如IGraphicProducer的setSidebandStream）被低权限进程跨进程触发。 更巧妙的是，作者构建了一条清晰的提权路径：从普通应用出发，必须按顺序依次注入mediaserver、surfaceflinger，最终目标是获得system_server的“半神”权限。摘要中点明了这一“三步走”策略的必要性——每一步获取的权限是攻击下一步的门票。文中还提及了攻击过程需克服的ASLR、SELinux以及je_malloc堆管理器等现实障碍，并以mediaserver注入为例，详细拆解了从控制Binder服务线程到最终代码注入的五个步骤。整篇文章不仅定位了漏洞根源，更完整呈现了从漏洞发现到实现高权限提权的复杂工程化利用全貌。
Android安全–加强版Smali Log注入
这篇讲的是如何在Android逆向或调试时，更高效地向Smali代码注入日志打印。作者从实际场景出发：当我们需要在Smali中插入`Log.d()`来输出某个变量的值时，常规做法很繁琐，往往需要手动修改方法的寄存器数量，再添加多行指令，容易出错且效率低下。 为了解决这个痛点，作者提出了一种巧妙的“加强版”方案。核心思路是自己创建一个`crack.smali`工具类，并在其中预先定义好几个好用的日志输出函数（如`log1`、`log2`等）。这样一来，在需要注入日志的地方，只需简单调用这个类中对应的方法，并将要打印的变量作为参数传入即可。 这种方法将通用操作封装成了模块，避免了每次注入时重复编写和调整基础的Log代码，既降低了出错概率，也大幅提升了逆向分析或调试的效率。文章通过具体的Smali代码示例，清晰展示了从繁琐到简洁的转变过程，对于经常需要动态分析APK的开发者来说，是一个非常实用的技巧。
NodeJs下的Web安全
这篇文章聚焦于Node.js应用面临的Web安全威胁及防御之道。它系统地拆解了从基础到进阶的多种攻击模式，每种都清晰地阐述了攻击原理与具体防范措施。 比如，针对SQL注入，文章展示了恶意参数如何拼接出`drop table`的毁灭性语句，并强调对用户输入进行过滤是关键。对于XSS脚本攻击，作者提醒要保持对用户数据的怀疑，并推荐了具体的过滤模块。文章还深入讲解了CSRF请求伪造、HTTP管道洪水漏洞，以及包括Slowlori慢速攻击、超大Buffer耗尽内存在内的多种应用层DoS攻击手法。 除了这些经典问题，内容也延伸至Node.js开发中特有的风险点，如因直接拼接文件路径导致的目录遍历漏洞，以及MD5等传统加密方式因彩虹表而变得不安全的现状。文末的总结建议，将Node.js应用部署在Nginx之后、对输入进行严格过滤，是极具操作性的生产环境防护指南。
bash代码注入的安全漏洞
这篇文章深入剖析了2014年被称为“Shellshock”的Bash代码注入漏洞。作者从继“心脏流血”后又一“毁灭级”安全事件切入，详细拆解了漏洞的检测方法与技术原理。核心在于Bash处理环境变量时，会错误地执行函数体定义之外的恶意代码——这个缺陷从Bash 1.14一直延续到4.3版本。 文章不仅解释了CVE-2014-6271和随后被发现修复不彻底的CVE-2014-7169，更关键的是，作者澄清了“该漏洞影响有限”的误解。他指出，只要服务器端应用（如PHP调用系统shell命令）会衍生出Bash子进程，就可能在传递环境变量时被注入恶意指令，这意味着许多现代系统都存在风险。 这不仅仅是对一个历史漏洞的技术复盘，更是对安全观念的提醒：看似底层的工具链漏洞，其冲击力可能远超想象，影响面覆盖了从Web服务到系统管理的广泛场景。
SSLStrip 的未来 —— HTTPS 前端劫持
这篇文章探讨的是在HTTPS日益普及的今天，传统的中间人攻击工具SSLStrip面临的挑战与进化。作者从后端劫持的局限性出发，指出SSLStrip这类纯流量层的工具在现代Web面前已力不从心，难以处理动态生成的链接、数据包分片以及高昂的性能开销。 核心思路因此转向“前端劫持”。通过向页面注入脚本，利用事件捕获机制（如监听全局点击事件），攻击者可以在用户点击链接的瞬间，临时将HTTPS地址修改为HTTP。这种方法巧妙地绕过了后端的种种问题：只需处理页面首个数据块即可完成渗透，对性能影响极小；同时能应对各种动态添加的链接，甚至表单提交、脚本弹窗和框架页面。文章详细解释了如何通过修改链接的href属性并在下个事件循环中还原，来实现实时且无痕的替换，比传统的DOM扫描轮询方案更为优雅和彻底。 本质上，这篇内容揭示了网络攻击手段随技术栈演进的路径——从粗放的流量篡改，转向更精细、更贴近应用层的前端逻辑操控。对于安全研究人员和前端开发者而言，它清晰地展示了一种新型攻击面的技术原理与实现细节。
WebView跨源攻击分析
这篇技术分析深入探讨了WebView中的跨源安全问题。作者从浏览器最核心的同源策略（SOP）讲起，通过清晰的表格对比了不同URL是否同源，为后续分析打下基础。 文章重点剖析了Android WebView中与`file://`协议相关的几个关键API配置：`setAllowFileAccess`、`setAllowFileAccessFromFileURLs`和`setAllowUniversalAccessFromFileURLs`。作者通过代码示例和机制解释，揭示了当这些开关设置不当时，恶意网页如何利用`file://`协议绕过同源策略，读取应用沙箱内的任意文件，造成严重的安全风险。文中还提到了不同浏览器对`file://`协议处理的差异，增加了讨论的深度。 对于从事移动端开发或安全研究的读者来说，这篇文章清晰地梳理了WebView配置中那些看似平常却可能致命的开关。理解这些细节，是构建安全WebView应用的基础。
WebView跨源攻击分析
这篇讲的是WebView安全中一个核心但常被忽视的问题：同源策略在本地文件场景下的边界。 作者龚广从浏览器同源策略的基本原理讲起，用一个清晰的对比表格说明了协议、域名、端口三要素如何共同决定URL的同源性，比如“http://www.360.cn:8088”因端口不同就与基准URL非同源。文章的核心深入到了file协议这个特殊领域：当JavaScript通过http页面加载时，file协议通常被视为非同源以阻止读取本地文件；但当JS本身通过file协议加载时，不同浏览器的处理策略则存在显著差异，这为攻击留下了可能的缝隙。 具体到Android WebView，文章通过示例代码展示了四个关键API设置——从是否允许加载file URL，到是否允许file URL中的JS进行跨域访问。这些配置如同一组开关，开错一个就可能让应用暴露在风险中。文章没有停留在理论，而是将同源策略的复杂边界与移动开发的具体实践结合，揭示了WebView安全配置中那些看似细微、却至关重要的决策点。
XSS 前端防火墙 —— 可疑模块拦截
这篇讲的是，如何为XSS前端防火墙增加对可疑脚本模块的主动拦截能力。作者从上一代系统的不足出发——虽然能防简单的内联代码，但面对站外脚本加载和代码混淆时束手无策——提出了一套基于DOM监视的“可疑模块跟踪系统”。 文章的核心探索，围绕着HTML5提供的MutationEvent接口（包括DOMNodeInserted事件与MutationObserver）展开。通过大量实测代码，作者验证了这套方案在检测层面的有效性：MutationObserver能批量捕获静态脚本，DOMNodeInserted则对动态创建的元素响应更及时。更进一步，实验证明利用MutationObserver甚至可以在脚本加载前将其从DOM中移除，实现对静态脚本的拦截，但在动态脚本和跨浏览器一致性上遇到了限制。 作者并未止步于事件监听，而是深入分析了动态脚本创建的全过程，尝试了在属性赋值阶段进行拦截的更高阶思路。整篇文章并非提供一个完满的最终方案，而是详实记录了一次充满实验与思考的技术攻坚过程，展现了在浏览器环境限制下，为前端安全“打补丁”的真实挑战与巧妙尝试。
php中assert方法的安全问题
这篇讲的是PHP中`assert`函数的安全隐患。`assert`本是调试利器，当代码中的表达式为假时，它会发出警告而不中断执行，还能通过`ASSERT_CALLBACK`自定义处理逻辑，为调试提供了灵活控制。 然而，作者立刻点明：这种便利在生产环境中可能变成危险。`assert`的真正问题在于它会执行传入的字符串参数。文章通过一个直观的代码示例揭示了风险：若将未经验证的用户输入（`$_GET['func']`）直接拼接到`assert`语句中，攻击者就可能执行任意代码。例如，传入`func=file_put_contents('a.php','恶意内容')`，就会在服务器上创建文件，其危害可能比`eval`更严重。 因此，文章得出的明确结论是：`assert`仅适用于调试阶段。在部署到生产环境前，应当彻底禁用它，或确保其参数完全是可信的内部逻辑，从而杜绝因输入过滤疏忽而导致的严重漏洞。
云存储中的HTTP鉴权算法分析
云存储的安全高度依赖鉴权机制，传统的HTTP基本认证（Base64编码用户密码）因易被截获和反向解析，已无法满足云环境的安全需求。这篇文章对比了两大主流云平台——AWS S3与OpenStack Swift——为解决此问题所采取的不同鉴权路径。 AWS S3采用了基于请求签名的算法。其核心是每次请求时，客户端将请求元信息与私钥(SecretAccessKey)组合，通过SHA256哈希生成一个签名值随请求发送。服务端用同样方法计算签名并比对。即便请求被截获，攻击者也无法反推私钥，且签名与特定请求绑定并有时效性（15分钟），有效防范了密钥泄露和请求重放风险。 相比之下，OpenStack Swift依赖Keystone服务发放的Token。客户端先用账号密码换取一个有效期Token，后续请求都需携带。服务端每次向Keystone验证Token的有效性。这种方式架构更集中，便于多服务共享鉴权。但缺点也明显：Token泄露风险较高，且每次请求都需额外验证，可能带来性能开销，历史上还出现过Token永久有效的Bug。 两者的选择反映了不同的权衡：AWS S3在每次请求层面实现细粒度、高强度的安全；OpenStack Swift则追求服务治理的便捷与统一，但需在Token生命周期和验证效率上做好管控。