文件权限之粘滞位
这篇讲的是Unix/Linux系统中一个具体而微小的技术点：粘滞位（Sticky Bit）在可执行文件上的行为。作者从一个实际问题出发——如果给一个root属主的可执行文件设置了粘滞位，那么由它派生的其他进程，其有效用户ID（euid）还会是root吗？ 为了验证，作者编写了一个简单的PHP脚本（test.php），其核心就是输出当前进程的euid和uid。随后，他通过给这个脚本文件设置粘滞位并以root身份执行来观察结果。测试发现，新进程的euid并没有如预期那样保持为root。 由此得出一个明确的结论：粘滞位（即使在可执行文件上）并不能在程序执行后被其创建的其他进程所继承。这个发现澄清了对文件权限位作用范围的一个常见误解。
给Nginx配置一个自签名的SSL证书
这篇讲的是如何为Nginx配置一个自签名SSL证书，来快速启用HTTPS安全连接。 在Web开发中，HTTPS几乎是保障浏览器与服务器通信安全的必选方案，但向证书颁发机构申请正式证书往往需要每年几十到几百美元的费用。如果只是为了内部管理或测试目的，自签名证书就能提供一个零成本的解决思路。 文章从SSL证书验证的两种模式切入，解释了为什么普通网站通常只验证服务器证书，并点明自签名证书的适用场景。核心方案部分，作者详细演示了利用openssl创建证书的四步流程：生成密钥、创建签名请求、移除口令并最终签名。为了简化操作，文章还提供了一个shell脚本，以域名www.test.com为例，展示了从运行脚本到输入口令的完整交互过程，以及生成的四个关键文件。 配置环节，文章明确指出Nginx需要加载证书和密钥文件的具体路径，并附上了示例配置。最后还提到一个实用技巧：让Nginx统一处理HTTPS，后端应用服务器只用HTTP连接，这样既发挥了Nginx在处理SSL方面的优势，也避免了其他服务器配置证书的复杂性。整个过程下来，即使是自签名证书，也能让管理员通过浏览器安全地连接到服务器进行维护。
记一次LVS/Nginx环境下的访问控制
作者从一次监控异常出发，揭示了LVS/Nginx架构下访问控制的典型陷阱。他在Graphite上发现服务器网卡流量
HTTPS, SPDY和 HTTP/2性能的简单对比
这篇翻译文章源于作者对抗运营商网络劫持的关注，借此机会详细对比了传统HTTPS、SPDY/3.1以及新兴的HTTP/2协议在性能上的具体差异。 测试以Google英国首页为例，在相同条件下对比三者。一个关键区别在于报头压缩：HTTP/2采用的HPACK算法，在报头大小上显著优于SPDY所使用的DEFLATE压缩，使得HTTP/2的空请求报头体积最小，优势明显。 在响应信息大小方面，情况则更为复杂。对于图片资源，三者表现相近。但对于文本内容，虽然HTTP/2报头更小，但其数据帧的可选填充字节，使得最终响应信息反而大于SPDY。文章解释，这种填充机制主要是为了对抗如BREACH等特定安全攻击。 总体来看，HTTP/2在连接初期的数据传输效率上建立了优势，尤其是在报头处理上更为高效。而SPDY在某些特定内容的传输中依然保持着竞争力。文章通过具体的截图和数据，清晰地展示了下一代网络协议在优化性能与保障安全方面的不同设计权衡。
网络数据包调试利器之wireshark
网络调试中，Wireshark 是不少工程师离不开的“瑞士军刀”。这篇文章没有停留在概念介绍，而是直接带你走进 Wireshark 的实际操作现场。从如何在不同系统上安装开始，重点讲解了软件的核心使用流程。 文章细致拆解了 Wireshark 的主界面，并逐步演示了捕获数据包的关键设置。比如，如何选择网卡接口、理解混杂模式的用途以捕获局域网全部流量，以及如何设置像“port 80”这样的捕获过滤条件来提前筛选 HTTP 流量。 更实用的部分在于捕获后的分析环节。作者详细说明了如何使用显示过滤器，通过构建表达式来精确定位目标数据包。同时，介绍了着色规则和 IO 图表等可视化功能，这些都能帮助用户快速识别网络中的异常流量或性能瓶颈，比如通过 IO 图表直观发现 TCP 重传的低谷点。整篇文章像一份简洁的操作手册，让复杂的工具使用变得清晰可循。
什么才叫有操作性地尊重版权
这篇文章从近期界面、罗辑思维、中国企业家三起引发关注的版权道歉事件切入，深入探讨了数字时代版权的实际操作困境与可能出路。 作者首先厘清了版权（即著作权）的十七项具体权利，并指出其核心在于保护作品而非思想，且财产权可能已从原作者手中转让。文章的核心论证在于：传统版权体系是建立在“内容与介质不可分离”的现实上的，而数字化使得内容复制与传播的成本趋近于零，这导致整个体系的可操作性日益脆弱。在文字领域，严格维权的商业成本极高且效果有限。 对此，作者引用了互联网法律学者劳伦斯·莱斯格的观点，倡导一种更符合互联网精神的“创作共用”（CC）原则，即创作者可自主选择对他人开放部分权利。他以自身实践为例：对自己的文章，他欢迎署名转载，以此促进传播；而对他人的文章，他则坚持注明出处、仅作摘要并链接原文，以示尊重。文章最终主张，在保障人身权的前提下，创作者或许可以对自己“宽松”，对他人“严谨”，因为传播本身才是数字时代的核心要义。
C语言的整型溢出问题
这篇讲的是C语言中一个常被忽视但极其危险的安全陷阱：整型溢出。作者从“无符号整型溢出有定义（模运算），而有符号整型溢出是未定义行为”这个核心区别出发，拆解了问题的根源。 文章的重点在于揭示溢出带来的真实危害，并用四个具体示例生动说明。例如，一个简单的`while`循环可能因`short`溢出而变成死循环；一次看似安全的内存拷贝检查，会因`int`到`size_t`的隐式类型转换而被绕过，导致缓冲区溢出。更严重的案例直接关联到OpenSSL的Heartbleed漏洞，展示了如何通过精心构造的输入，让`malloc`分配的内存远小于预期，从而引发远程代码执行。 作者还特别提醒了编译器优化带来的“反直觉”行为：编译器在`-O2`等优化级别下，会假定有符号整型不会溢出，从而直接删除你手写的溢出检查代码。这意味着，那些在调试版本下有效的保护措施，可能在发布版本中完全失效，这使得问题更加隐蔽和致命。 整篇文章就像一份简洁的安全编码警示录，它没有停留在理论定义，而是通过剖析编译器行为和真实漏洞，提醒开发者在处理整数时必须如履薄冰，尤其是在涉及内存操作和用户输入的场景中。
调试利器之tcpdump详解
讲的是网络排查必备的工具tcpdump。文章开篇点明其“dump traffic on a network”的本质——一个功能强大、可扩展的包分析工具，能深入到网络层、协议、端口进行过滤和抓取。 安装部分是这篇文章的一个重点。作者详细拆解了三种途径：最省心的yum命令安装、稍麻烦但直接的rpm包安装，以及最繁琐但能获取最新源码的编译安装。对于源码编译，还贴心地提示了可能遇到的libpcap依赖问题及解决方法，比如需要先安装flex、bison和m4等，这对新手排坑很有帮助。 工具的基本使用也是核心。文章列举了tcpdump纷繁复杂的命令行参数，并对其中常用的选项，如`-A`（ASCII码查看）、`-i`（指定接口）、`-w`（写入文件）等，配合具体命令示例解释了它们在不同场景下的用途。例如，用`-A`参数可以直观看到MySQL通信的SQL语句原文，用`-w`抓包后配合Wireshark分析则能解决更复杂的问题。 整体来看，这篇文章从安装到实战，为初学者搭建了清晰的tcpdump入门路径，强调了它在网络诊断和安全分析中不可替代的作用。
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安全配置中那些看似细微、却至关重要的决策点。
SSL证书的分类（按功能）
这篇文章系统地梳理了SSL证书的六大分类，从最基础的DV域名型证书到企业级的OV、EV增强型证书，再到功能扩展的通配符、多域名及强制加密证书。它清晰地对比了各类证书在验证严格程度、包含信息、颁发周期和价格成本上的核心差异。例如，DV证书仅验证域名所有权，一两小时内即可签发，适合个人或中小网站快速启用加密；而OV和EV证书则需严格的企业身份审查，其中EV证书还会在浏览器地址栏直接显示公司名称，为金融机构等高要求场景提供最高级别的信任标识。对于拥有多个子域名或不同顶级域名的企业，通配符证书和多域名证书则分别提供了“一张证书保护所有子站”和“统一管理多个域名”的高效解决方案。文章不仅解释了技术定义，更通过适用对象的罗列，让读者能根据自身网站的性质、规模和安全需求，快速定位到最合适的证书类型，具有很强的实操参考价值。
Linux使用curl访问https站点时报错汇总
这篇整理了在使用Linux的curl命令行工具访问HTTPS站点时，几类最常见的证书相关报错及其解决方法。文章指出，问题的根源往往在于不同客户端（如curl、浏览器、Java程序）使用独立的证书库，而Linux的curl默认依赖位于 `/etc/pki/tls/certs/ca-bundle.crt` 的文件。 摘要列举了四种典型情况：遇到“Peer’s Certificate issuer is not recognized”时，多是由于自签名证书未被信任，解决方法是将私有CA的公钥追加到系统证书库中。而“certificate verify failed”错误，则常因本地CA证书库过旧，无法识别新签发的证书，需要下载最新的cacert.pem进行替换或使用系统命令更新。当遇到“unknown message digest algorithm”时，根源在于系统的OpenSSL版本过低，不支持如SHA-256等新算法，升级OpenSSL是必要步骤。 文章最后还对比了Java和PHP处理HTTPS的机制，指出它们拥有自己的证书库（如Java的cacerts），与系统curl的证书库相互独立。整篇文章以实战报错为线索，提供了直接的操作路径，对于解决这类环境配置问题很有参考价值。
php中assert方法的安全问题
这篇讲的是PHP中`assert`函数的安全隐患。`assert`本是调试利器，当代码中的表达式为假时，它会发出警告而不中断执行，还能通过`ASSERT_CALLBACK`自定义处理逻辑，为调试提供了灵活控制。 然而，作者立刻点明：这种便利在生产环境中可能变成危险。`assert`的真正问题在于它会执行传入的字符串参数。文章通过一个直观的代码示例揭示了风险：若将未经验证的用户输入（`$_GET['func']`）直接拼接到`assert`语句中，攻击者就可能执行任意代码。例如，传入`func=file_put_contents('a.php','恶意内容')`，就会在服务器上创建文件，其危害可能比`eval`更严重。 因此，文章得出的明确结论是：`assert`仅适用于调试阶段。在部署到生产环境前，应当彻底禁用它，或确保其参数完全是可信的内部逻辑，从而杜绝因输入过滤疏忽而导致的严重漏洞。
初探单点登录 SSO
这篇讲的是单点登录（SSO）的基本原理，并通过淘宝与京东的实例，对比了两种主流实现策略的差异。 文章先阐释了SSO如何解决多产品线下的用户体验问题，即“一次登录，处处通行”。其核心在于认证系统为每个应用颁发“钥匙”（存于Cookie）。关键差异在于应用间如何获取这把钥匙。 作者通过抓包分析揭示了两种路径：淘宝的策略更偏向“后置式”，用户访问聚划算等未登录站点时，通过一系列跳转，由主站（taobao.com）的凭证去认证中心为当前站点领取新凭证。而京东的策略则是“前置式”，用户登录主站（jd.com）后，页面中的JS代码会立即通过JSONP跨域请求，主动为旗下所有子应用预置好登录凭证，实现更无缝的体验。 这种基于实际网络请求的剖析，清晰展示了SSO在“便利性”与“安全流程”之间的权衡，对于理解企业级统一认证架构的设计思路很有启发。
云存储中的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生命周期和验证效率上做好管控。
如何获取用户访问过哪些网站
这篇文章探讨的是如何在用户不知情的情况下，间接推断其浏览器历史记录，这在分析用户习惯或竞品时很有价值。直接读取历史或通过Cookie获取是行不通的，但作者介绍了几个巧妙的“曲线救国”技术方案。 最经典的是利用CSS的 `:visited` 伪类。已访问链接默认为紫色，未访问为蓝色，通过JS检测这种颜色差异，理论上就能判断用户是否访问过特定网站。不过，由于隐私安全考量，Chrome、Safari等主流浏览器已修复此漏洞，目前该方案可能只在IE上仍有效。 另一个更前沿的思路来自2013年的黑客大会，利用HTML5的 `requestAnimationFrame` API进行“时间差攻击”。浏览器渲染已访问和未访问的链接时，从数据库查询URL是否存在会有微小的时间差异，通过高精度计时就有可能推断出访问历史。此外，文章还提到了一个未验证的思路：尝试请求网站的 `favicon.ico` 文件，通过缓存命中导致的响应时间差异来辅助判断。 这些方案从不同角度切入，共同揭示了浏览器在历史记录处理上存在的隐私泄露风险，也提醒开发者需持续关注相关安全更新。
如何安全的Include文件
这篇讲的是PHP开发中一个容易被忽略的陷阱：include外部文件时可能引发的变量污染问题。作者从一个看似简单的调试开关案例出发，揭示了配置文件中的临时变量如何悄悄覆盖主脚本的变量，导致程序行为异常——就像二战时阿登高地被绕过一样，安全之处往往藏着隐患。 文章指出，问题的根因在于include操作时文件内的变量直接进入了当前作用域。作者提供的解决方案很简洁：将include语句包裹在匿名函数中执行，利用函数创建独立的作用域。这种用call_user_func执行闭包来隔离变量作用域的做法，在JavaScript中很常见，但在PHP代码里却很少有人刻意运用。 对于日常编写PHP代码的开发者来说，这个技巧能有效避免因include文件带来的隐蔽bug，尤其在多文件协作或修改第三方配置文件时特别实用。作者通过这个具体场景提醒我们，那些“简单”的基础操作，恰恰需要多一分警惕。
HTTPS、SSL与数字证书介绍
这篇讲的是HTTPS、SSL与数字证书三者如何协同工作，共同构筑起现代互联网通信的安全基石。作者从安全通信的基本需求出发，清晰地拆解了HTTPS（安全的超文本传输协议）的本质——在HTTP和TCP之间加入一个加密层，而SSL（或其升级版TLS）正是实现这个加密层的关键协议。 文章没有停留在概念罗列，而是深入到了实现机制。它通过一个生动的A与B对话场景，形象地演示了SSL/TLS协议的“握手”过程：如何巧妙地结合非对称加密（用于安全地协商密钥）和对称加密（用于高效地传输数据）来平衡安全性与性能。同时，详细阐述了数字证书的核心作用——它如同网络世界的“身份证”，由权威的证书颁发机构签发，用于验证服务器身份并分发公钥，从而防止中间人攻击。 对于证书的信任链，文章也给出了直观解释：客户端（如浏览器）内置了受信任的根证书列表，只有由这些机构颁发的证书才会被信任。整体而言，这篇文章将抽象的安全概念落到了具体的协议交互与文件验证上，是理解HTTPS工作原理的一篇扎实导读。