您现在的位置：首页
--> 安全
经过努力，作者已经打到了第三关，这一关叫做“命令执行关”。也不知道是因为作者描述不清楚，还是SAE的理解出现偏差，我们没有直接沟通过，只是作者写篇文章，先交给那边“审核”，“审核”通过后，才发布了，所有的交流，都仅限于文章本身。这种沟通的障碍，是此次绕过安全防御的起始。
(此漏洞新浪已修补) 本次bypass，是利用了SAE上的沙盒权限允许“crackClassLoader”做到的，绕过权限后，作者调用了系统命令，去读取其他云用户的源代码。沙盒，尤其是用在云上的沙盒，安全配置是很重要的，很多权限并不是可以随便交给用户的，这次有了crackCLassLoaer，基本上是一个最好用的提权办法了，其实还有很多其他的权限，都是很不安全的。这要仔细斟酌以后，才能开给用户，否则就是一个灾难。
ps:此漏洞，新浪已修复。新浪有云服务(SAE)，提供PHP、JAVA等环境，供用户搭建网站，用户都在同一个云上，为了防止恶意用户在云上面DDOS，旁注黑掉其他云用户什么的，所以必须做安全限制，至少不允许用户调用某些关键函数。java对这种需求，有完美解决方案的，提供安全沙盒，有了安全沙盒，就限制了很多函数。但是java也有出漏洞的时候，今年新出了漏洞CVE20120507，绕过安全JAVA沙箱，新闻上讲，这个漏洞被用来黑苹果电脑。这个漏洞相关的技术，老外有分析文，国内也有分析文，虽然作者还是抱有疑问，但是并没有深究，所以原理方面的东西，就不献丑了。本文的目的，是把这个漏洞换个场景利用起来。
在最近使用新浪微博android sdk开发微博登录的时候，从日志中发现一个问题，就是自定义的WeiboDialogListener里面的方法，比如onComplete或者onCancel等，经常会被两次调用，这样其实会导致一些隐性问题，比如增加额外的客户端和服务端的开销，因为我们通常会在onComplete()里面完成更多后续逻辑的处理，而发生这样的情况时，会被处理两次，一开始我犯懒，就在方法外面加入了一个变量 isCompleted 来进行判断，算是暂时解决了问题，后来在好几个地方要开发类似功能的时候，总感觉心里有点儿不爽，于是决定找找到底啥原因
继上次struts远程代码执行漏洞后，前段时间又发布了一个远程代码执行漏洞。影响范围极广，利用方式相对上次要苛刻一点，但是读完本文，批量抓鸡不难。
浮点数的存储格式与整数完全不同。大部分的实现采用的是IEEE 754标准，float类型，是1个sign bit，8 exponent bits，23 mantissa bits。而double类型，是1个sign bit，11 exponent bits，52 mantissa bits。至于浮点如何去表示小数，请自行搜索google。由于float使用的小数表示方法，导致浮点数值是有精度限制的。 有限的精度就引发了浮点数值使用时的两个陷阱。
在代码中还是要尽量避免有符号数和无符号数的比较。如果无法避免，为了清楚的表明自己的目的，最好使用强制类型转换。
这是一个随机函数破解的经典例子。在java程序中，获取随机数的做法有多种。但是我们实现一个随机token，并用于认证时，通常第一时间，想起来使用“System.currentTimeMillis”，本文会详细讲解一次破解随机数的经过。
最近哈希表碰撞攻击（Hashtable collisions as DOS attack）的话题不断被提起，各种语言纷纷中招。本文结合PHP内核源码，聊一聊这种攻击的原理及实现。 哈希表碰撞攻击的基本原理 哈希表是一种查找效率极高的数据结构，很多语言都在内部实现了哈希表。PHP中的哈希表是一种极为重要的数据结构，不但用于表示Array数据类型，还在Zend虚拟机内部用于存储上下文环境信息（执行上下文的变量及函数均使用哈希表结构存储）。 理想情况下哈希表插入和查找操作的时间复杂度均为O(1)，任何一个数据项可以在一个与哈希表长度无关的时间内计算出一个哈希值（key），然后在常量时间内定位到一个桶（术语bucket，表示哈希表中的一个位置）。
去年CSDN密码泄露案公布之后，很多专家跳出来讨伐说他家的程序员太白痴居然还在数据库里面存明文。最近linkedin的事件出来之后，如何保存密码，这个问题又被拉出来谈。我认为，密码怎么保存与怎么在网上传输，这两个问题不能分开来谈。除非你已经有了安全的信道，如SSL，否则还是存明文为妙。 mysql对其原始的CHAP协议做了些改进： storedhash=sha1(passphrase) reply=xor(passphrase, sha1(public_seed,storedhash) 在网络上发送的是public_seed、reply，数据库里面存储的是storedhash。所以如果只是拿到了mysql.user表里的数据，而没有原始的passphrase，想要构造出reply，还是挺困难的。不过我估计这个算法是工程师自己想出来的，根本就没找安全专家讨论过，未必经得起推敲。
在Web应用中，Cookie很容易成为安全问题的一部分。从以往的经验来看，对Cookie在开发过程中的使用，很多开发团队并没有形成共识或者一定的规范，这也使得很多应用中的Cookie成为潜在的易受攻击点。在给Web应用做安全架构评审（Security architecture review）的时候，我通常会问设计人员以下几个问题： 你的应用中，有使用JavaScript来操作客户端Cookie吗？如果有，那么是否必须使用JavaScript才能完成此应用场景？如果没有，你的Cookie允许JavaScript来访问吗？ 你的网站（可能包含多个Web应用）中，对于Cookie的域（Domain）和路径（Path）设置是如何制定策略的？为何这样划分？
• 哈希表之殇
2011年12月28日，由Google赞助成立的安全漏洞研究组织oCERT（Open source Computer Emergency Response Team — 开源软件应急响应团队）公开了一份安全漏洞报告。这份报告是几个月前由德国安全研究公司nrun.com所提供的，其核心内容是：目前绝大多数的web应用，都存在着一个叫做哈希碰撞式拒绝服务攻击的漏洞（Hash Collision DoS）。这份报告的公布，使得2011年剩下的几天里，各互联网公司的技术团队集体忙于对网站进行针对此漏洞的防护工作。硝烟散尽之后，让我们一起从攻击者的角度重新审视一下这个漏洞及其利用手法。
• 加密服务学习笔记
公共网络（如 Internet）不提供实体间安全通信的方法。这种网络上的通信容易被未经授权的第三方读取甚至修改。加密有助于防止他人查看数据，它提供了检测数据是否已被修改的方式，同时有助于在非安全信道上提供安全的通信方式。例如，可以使用加密算法对数据进行加密，在加密状态下传输数据，然后由预定的接收方对数据进行解密。如果第三方截获了加密的数据，解密数据是很困难的。 一、加密基元 在使用加密的典型场合中，双方（Alice 和 Bob）在不安全的信道上通信。Alice 和 Bob 想要确保任何可能正在侦听的人无法理解他们之间的通信。而且，由于 Alice 和 Bob 相距遥远，因此 Alice 必须确保她从 Bob 处收到的信息没有在传输期间被任何人修改。此外，她必须确保信息确实是来自 Bob，而不是来自模仿 Bob 的人。
在本文最后我想重申的是，对于不同的数据库产品，都存在足够成熟的安全实现手段，应用这些安全手段就能够实现对于数据的基本保护，对于我们技术人最重要的是：认识和重视数据安全问题，并逐步推动企业或组织应用安全手段进行数据安全增强。 重视数据，保护数据，重视数据安全问题，这是每一位技术人的共同使命！
这事可能都过气了，不过还是贴出我使用的方式吧，用的着的可以参考. 上段时间的各语言hash绝对印象深刻吧，做网站的几乎都在此类，不论你是用的是php，python还是ruby都不同程度受到影响, PHP尤其明显，因为PHP用的人也多嘛，攻击方式简直简单到不行，有兴趣的可以找我索取此测试脚本，一个终端随便搞挂一台有次漏洞的PHP站点. 我们http请求都是通过nginx反向代理，所以优势是可以在nginx这一层对请求做很多逻辑,此次防hash dos就是这个架构.
在前几天，我们运营的某网站遭受了一次ddos攻击，我们的网站是一个公益性质的网站，为各个厂商和白帽子之间搭建一个平台以传递安全问题等信息，我们并不清楚因为什么原因会遭遇这种无耻的攻击。因为我们本身并不从事这种类型的攻击，这种攻击技术一般也是比较粗糙的，所以讨论得比较少，但是既然发生了这样的攻击我们觉得分享攻击发生后我们在这个过程中学到得东西，以及针对这种攻击我们的想法才能让这次攻击产生真正的价值，而并不是这样的攻击仅仅浪费大家的时间而已。 另外，我们发现大型的企业都有遭受攻
把验证码存储在Cookie中 一般来说，我们会把验证码的值用Session存储起来，通过对比用户提交的验证码和Session中的验证码，就可以知道输入是否正确。由于Session会占用服务器资源，我曾经想过是否可以把验证码的值加密后存储在Cookie中。不过事实证明，这只是异想天开罢了。 假设验证码的值是a，通过sha1加密后得到的值为b = sha1(a)，并且把b存储在Cookie中。而用户提交的验证码值为c，通过判断sha1(c)是否与b相等，可以知道输入的验证码是否正确。然而，Cookie是受客户端控制的。如果用户事先通过肉眼看到验证码的值是a，又从Cookie中得知此时的加密值为b，那么，他只要在提交前把Cookie的值修改为b，提交的验证码值为a，就可以永远通过验证。
近3天十大热文
-
[17] [译]Google Chrome中的高性能网 -
[14] 关于Linux的文件系统cache
-
[14] 最近总结的一些技巧(vim,python,s
-
[14] 在FreeNAS/BSD搭建基于Nginx+
-
[13] Linux常用系统信息查看命令
-
[11] Linux(Ubuntu 10.04)上安装
-
[9] Centos yum 安装nginx+PHP
-
[8] base64_encode 和 urlenc
-
[7] nginx.conf控制指定的代理ip和ip
-
[7] 检查nginx配置，重载配置以及重启的方法
赞助商广告
