2013年2月16日星期六

预防Web应用程序的漏洞

  如今的Web应用程序可能会包含危险的安全缺陷。这些应用程序的全球化部署使其很容易遭受攻击,这些攻击会发现并恶意探测各种安全漏洞。

  Web环境中两个主要的风险在于:注入——也就是SQL注入,它会让黑客更改发往数据库的查询——以及跨站脚本攻击(XSS),它们也是最危险的(Category:OWASP_Top_Ten_Project)。注入攻击会利用有问题代码的应用程序来插入和执行黑客指定的命令,从而能够访问关键的数据和资源。当应用程序将用户提供的数据不加检验或编码就发送到浏览器上时,会产生XSS漏洞。

  尽管2009年OWASP(Open Web Application Security Project)的一个报告表明安全方面的投资在增加(Category:OWASP_Security_Spending_Benchmarks),但是NTA Monitor的2010 Web应用安全报名表明Web的安全性跟前一年相比实际在下降。实际上,Web应用的漏洞给公司和组织带来了很多的问题。按照WhiteHat Security最新的Web站点安全性数据报告所示,被评估网站的63%是有漏洞的,每个平均有六个未解决的缺陷。(WhiteHat Website Security Statistics Report)。这些漏洞创建并维持了一个基于攻击窃取数据和资源的地下经济链。

  Web应用程序需要有深度防御的措施来避免和减少安全性漏洞。1这种方式假设所有的安全预防措施都可能失败,所以安全性依赖于多层的机制从而能够覆盖其他层的失败。为了减少成功攻击的可能性,软件工程师团队必须做出必要的努力来引入适当的安全性防护措施。要达到这一点必须使用各种技术和工具来确保安全性涵盖软件产品开发生命周期的所有阶段。

  软件开发生命周期中的安全性

  尽管软件开发的生命周期有多种不同的划分方式,但正如图1所示,它通常包含如下的阶段:初始化、规范和设计、实现(编码)、测试、部署以及停用,这些阶段应用开发人员可以不断地重复迭代。2

  尽管开发人员应该在产品的整个生命周期中都关心代码安全性,3但是他们应该特别关注三个关键阶段:1

  • 实现。在编码过程中,软件开发人员必须使用特定应用领域内避免关键漏洞的最佳实践。这种实践的例子包括输入和输出校验、识别恶意字符以及使用参数化的命令。4 尽管这些技术在避免大多数安全漏洞方面很有效,但因为缺乏安全相关的知识,开发人员通常并不使用它们或者使用得不正确。边栏“为什么开发人员不使用安全编码实践?”更详细地讨论了这个问题。
  • 测试。有很多技术可以在测试阶段使用,包括渗透测试(目前最流行的技术)、静态分析、动态分析以及运行时的异常检测。4 问题在于开发人员通常会关注需求功能的测试而忽略安全方面。另外,现有的自动化工具要么在漏洞探测覆盖度方面比较差要么产生太多的误报。
  • 部署。在运行时环境中,会有不同的攻击探测机制。这些机制可以按照不同的级别运行并使用不同的探测方式。它们的使用障碍在于性能开销以及不准确的结果会打乱系统的正常行为。

预防Web应用程序的漏洞

  开发安全的代码

  为了编写没有漏洞的安全代码,4 基于Web基础设施的关键业务开发人员就要遵循编码实践,这个实践包括了深度防御的措施,它假设所有的安全性预防措施都会失败。在实现阶段依赖多层的安全机制是特别重要的,使用一个预防或保护措施来避免安全漏洞是不够的。

  Web应用程序的特征在于需要三层不同的安全防线:输入校验、热点保护以及输出校验。

  输入校验

  大多数的安全漏洞是因为目标应用程序没有正确地校验输入数据。1所以,应用程序要考虑到所有恶意的输入直到能证明其合法,这要涵盖不可信环境中的所有数据。

  输入校验是第一道防线,总体来讲就是缩小应用程序允许输入的范围,它会直接作用在用户提供的数据上。这种类型的防御要依赖输入参数在一个合法的范围内,或者如果用户提供了超出了范围的值就会停止执行。在Web应用程序中,这首先要标准化输入将其转换到基线字符集和编码。接下来,应用程序必须对标准化的输入使用过滤策略,拒绝那些值在合法范围之外的输入。这种方式能够避免很多Web应用程序中的问题,在执行输入校验时会使用正向模式匹配或正向校验。在这种情况下,开发人员建立规则来识别那些可接受的输入而不是识别有什么输入是不可接受的。尽管开发人员不能预测所有类型的攻击,但他们应该能够说明所有类型的合法输入。

  关键问题在于,输入校验通常使用地并不充分,这是因为输入参数的数据域允许存在恶意数据,这是与校验执行相独立的。例如,在SQL注入漏洞中,大多数的SQL语句使用引号作为字符串分隔符,这就意味着黑客可以使用它来执行SQL注入攻击。4但是,在有些情况下,字符串输入域必须允许存在引号值,所以应用程序不能排除所有包含引号的值。

  热点防护

  为了应对输入校验的局限性,有必要采用第二道防线

  任何类型的攻击都是以热点为目标的,热点指的就是应用程序中可能会有某种类型漏洞的代码。通用的输入校验会在应用程序中进行或者在整个Web应用程序上下文中修改输入,与之相比,第二道防线关注于保护重要的热点,例如保护那些真正使用输入域值的代码行。

  一个具体的例子就是SQL注入攻击,它们大多数会使用单引号或双引号。有些编程语言提供了对这些字符的转码机制,这样它们就能用在SQL语句中了,但是只能用来在语句中分隔值。4但是这些技术有两个问题。第一,更高级的注入技术,例如联合使用引号和转义字符,可以绕过这些机制。第二,引入转义字符会增加字符串的长度,如果结果字符串的长度超过数据库限制的话,可能会导致数据截断。

  正确使用参数化命令是预防注入攻击最有效的方式。1在这种情况下,开发人员定义命令的结构,并使用占位符来代表命令的变量值。稍后,当应用程序将对应的值关联到命令上时,命令解释器会正确地使用它们而不会涉及到命令的结构。

  这种技术最著名的用法是数据库的预处理语句,也被称为参数化查询。4 当应用程序创建预处理语句时,语句发送到了数据库端。应用程序使用占位符来表示查询的可变部分,占位符通常会是问号或标签。随后,每次查询执行时,应用程序都要往对应的可变部分绑定值。不管数据的内容是什么,应用程序会一直使用这个表达式作为一个值而并没有SQL代码。因此,不可能修改查询的结构。

  为了确保正确使用数据,很多语言允许类型绑定。但是预处理语句本身并不能修复不安全的语句——开发人员必须正确地使用它们。例如,像传统语句一样使用预处理语句——也就是使用字符串拼接来绑定SQL查询——而不是对查询的可变部分使用占位符会导致类似的漏洞。

  输出校验

  在将一个进程的输出发送之前进行校验能够避免用户收到他们不应该看到的信息,例如应用程序内部的异常细节,这些信息有助于发起其他的攻击。在输出校验的另一个例子当中,保护系统会搜索应用程序输出的关键信息,如信用卡号,并在发送给前端之前用星号代替。将信息编码是能够避免XSS漏洞的一种输出校验方式。4如果发送给浏览器的数据要显示在Web页面上,它应该进行HTML编码或百分号编码,这取决于它在页面的位置。通过这种方式,XSS所用的恶意字符不再具有破坏性,而且编码会保留数据的原来意义。

  探测漏洞

  识别安全的问题要求不仅测试应用程序的功能还要寻找代码中可能被黑客利用的隐藏的危险缺陷。5探测漏洞的两个主要方式是白盒分析和黑盒测试。

  白盒分析

  白盒分析需要在不执行的情况下检查代码。开发人员可以按照以下两种方式中的某一种来进行:在代码的审查或评审时以手动方式进行或者借助自动分析工具自动化进行。

  代码审查(Code inspection)指的是程序员的同伴系统检查交付的代码,查找编码错误。6安全审查是减少应用程序中漏洞最有效的方式;当为关键的系统开发软件时,这是重要的过程。但是,这种审查方式通常是很费时间的、代价昂贵并需要深入了解Web的安全知识。

  代码检查(Code review)是代价稍为低廉的替代方案,6它是一种简化版本的代码审查适用于分析不像前面那么重要的代码。检查也是手动进行的,但是它不需要正式的审查会议。几个专家分别进行检查,然后由主持人过滤和合并结果。尽管这是一个有效的方式,但代码检查的成本依旧是很高的。

  为了减少白盒法分析的成本,开发人员有时依赖自动化工具,如静态代码分析器。静态代码分析工具会检查软件代码,要么是源码格式要么是二进制格式,并试图识别出常见的编码级别缺陷。4 使用现有工具所执行的分析会因为它们的复杂性而有所不同,这种差异体现在考虑单条语句和命令或考虑代码行之间的依赖。除了模型检查和数据流分析等功能之外,这些工具还会自动关注可能的编码错误。它的主要问题在于细致的分析是很困难并且因为源码的复杂性和缺乏动态(运行时)的视角有很多安全缺陷很难被发现。

  尽管使用静态代码分析工具很重要,但是它有时会降低开发人员的生产效率,这主要是因为误报,这会导致没有用处的额外工作。7为了避免这种情况,除了要有足够的时间学习怎样使用这些工具以外,开发人员需要一些策略来保证正确使用这些工具。例如,有必要指定规则来分类和选择开发人员应该处理的警告信息。同时,开发人员还要配置分析工具只报告那些与当前开发上下文相关的警告。没有接受怎样使用静态分析训练的开发人员最终会低估它的真正效益并且通常不能发挥它的所有功能。

  黑盒测试

  黑盒测试指的是从外部的视角分析程序的执行。简而言之,它会比较软件执行的输出与期望的结果。5 对于软件的检验和确认来说,测试可能是最常用的技术了。

  对于黑盒测试来讲,有多种级别,从单元测试到集成测试再到系统测试。测试方式可以是正式的(基于模型和定义良好的测试规范)也可以不那么正式(被称为“冒烟测试”,一种粗糙的测试目的是快速暴露简单的缺陷)。

  健壮性是黑盒测试一种特殊形式,它的目标是查看系统在错误输入条件下的行为。渗透测试是特殊类型的健壮性测试,它会分析在遇到恶意输入时的代码执行并查找潜在的漏洞。在这种方式中,测试人员使用模糊技术,这包含通过HTTP请求,提交意料之外的或非法的数据项到Web应用程序上并检查它的响应。4测试人员不需要了解实现细节——他们在用户的角度来测试应用程序的输入。对于每种漏洞类型,可能会有上百次甚至上千次的测试。

  渗透测试工具会自动搜索漏洞,这避免了手工为每种类型的漏洞构建上百个甚至上千个测试所带来的重复和乏味的工作。Web应用的常见自动化安全测试工具一般会称为Web应用或Web安全扫描器。这些扫描器可以很容易地测试应用程序以发现漏洞。对于目标应用,它们会有一些预定义的测试用例,所以用户只需要配置一下扫描器并让它测试应用即可。一旦扫描器完成测试,它会报告所探测到的漏洞。大多数的扫描器都是商业产品,尽管也有免费的应用程序扫描器,但是与商用版本相比,它们缺少大多数的功能所以用的很有限。

  漏洞探测的局限性

  渗透测试和静态代码分析可以是手动的也可以是自动化的。因为手动测试或检查需要特殊的安全资源并且很费时间,所以对于Web应用的开发人员来说自动化工具是常见的选择。当考虑漏洞检测工具的局限性时,很重要的一点就是安全测试是很困难的。确实,衡量应用程序的安全性是很有挑战性的:尽管发现一些漏洞可能很容易,但是保证应用没有漏洞是困难的。1

  渗透测试和静态代码分析工具都有其固有的局限性。渗透测试依赖于有效地代码执行,但是在实践中,漏洞识别时只会检查Web应用的输出。所以,缺少查看应用的内部行为会限制渗透测试的有效性。

  另一方面,详尽的源代码分析可能比较困难。代码的复杂性以及缺少动态(运行时)的观察可能会阻止发现很多安全缺陷。当然,渗透测试不需要查看源码,但是静态代码分析需要。

  使用错误的检测工具会导致部署的应用含有未检测出的漏洞。图2比较了在Web服务中,知名的并广泛使用的渗透测试和静态分析工具在检测SQL注入漏洞中的表现。8结果显示静态代码分析工具——包括FindBugs、Fortify 360以及IntelliJ IDEA(在图中匿名为SA1到SA3)——的覆盖度通常高于渗透测试工具,包括HP WebInspect、IBM Rational AppScan、Acunetix Web Vulnerability Scanner以及科英布拉大学开发的一个原型工具(在图中匿名为VS1到VS4)。这两种方式都有的一个问题就是误报,但是在静态分析中更明显。一个重要的发现在于相同方式下的不同工具对于相同的代码通常报告不同的漏洞。

预防Web应用程序的漏洞

  根据研究结果,需要强调工具的局限性使得有必要提高漏洞检测的有效性,比如这可以通过联合使用多种方式来实现。另外,开发人员需要定义一种机制来评估和比较不同的工具,这样它们才能选择最适合各种开发场景的工具。

  检测攻击

  为了防止对Web应用的攻击,软件工程师必须实施攻击检测机制,通常称为入侵检测系统(intrusion detection system,IDS)或Web应用防火墙(WAF)。不同的工具可以作用在应用或网络级别甚至在应用的资源上,如数据库,它们可以使用不同的方式如异常检测或签名匹配来检测攻击。

  检测攻击的方法

  检测攻击要区分出与所学习行为的差别。攻击检测工具所使用的方式要么基于异常检测要么基于签名。8

  异常检测通常需要一个训练阶段。训练阶段会展现系统的无恶意请求,工具会在给定的架构级别观察它的行为并学习正常的操作。这些工具会考虑到每个Web应用程序的细节,但如果应用程序的正确行为发生了变化或学习不完整的话,会产生很多错误的警告。

  相比之下,基于签名的工具会查找预定义的一组规则模式或标示攻击的签名。因为这些签名通常是独立于应用的,所以工具的成功与应用程序的运行配置文件或任何训练过程无关。

  在网络级别进行操作的工具通常会监视和分析网络流量,以保证攻击在到达Web应用之前检测到。工作在应用级别的攻击检测工具会分析发送给应用的请求并试图利用服务端程序和请求中参数的特定关系。工作在资源层的工具会保护与每种漏洞类型相关的资源。这些工具会在应用层之下并接近受保护的资源。一个常见的例子是监控对数据库服务器的访问来检测SQL注入的IDS。

  工具使用各种策略来收集应用请求以及可能收到攻击的信息。一些工具会使用嗅探策略来监控和分析通过网络传输的数据以此来观察HTTP流量,但是加密、编码以及封装可能会限制其有效性。同时,网络上可能会承载大量与受保护应用无关的数据。另一些工具会分析应用产生的日志甚至是应用所在服务器所产生的日志。尽管这种策略不会直接延迟对应用的请求,但是受限于日志中可以得到的信息。

  而另一种策略就是在请求的来源和受保护的应用或资源间引入一个代理。这能够很容易地阻止攻击,因为它提供了关于目标应用或资源的有用信息,但是,它引入了不良的延时从而会影响应用的正常行为。

  检测攻击的局限性

  因为每个Web应用程序的细节会影响到攻击检测工具的表现,同时工具所运行的架构级别也会有所影响,所以它们的实际效果通常是未知的。10大多数工具的检测覆盖比较低(在很多场景下,低于20%),同时它们还会有很多误报(高达所产成警报的50%)。此外,有些工具在特定的场景下展现的结果很好,但是在其他场景下所提供的结果很差。

  数据库级别的工具通常比应用级别的工具表现更好一些,10不过它们会产生一些关于请求的误报,这些请求是不会成功攻击数据库的。基于异常检测的工具对于简单的应用表现得更好,而基于签名的工具对于复杂的应用表现更好。在简单的应用程序中,工具能够学习并且更好地描述行为,因此从模式中检测偏差会更准确。实际上,异常检测的成功取决于训练阶段。如果训练不完整或者应用的正常操作配置在训练后发生了变化,那么攻击检测工具的有效性会降低。

  使用这些工具的开发人员有时缺乏创建适当配置的培训。这会减少工具的有效性,这凸显了评估和对比不同工具及配置的重要性。10

  新的趋势和方向

  要达到更好的结果并提高有效性需要新的技术来克服漏洞检测工具的局限性。但是要克服这些局限性并不容易,因为它需要将传统方式改为颠覆性的方法。关键在于释放一些约束并将不同的方法结合起来以克服单个方法的局限性。

  Acunetix AcuSensor就是一个商业技术的例子,它将黑盒扫描和测试执行反馈结合起来。反馈来自于植入到目标应用程序代码中的传感器(sensor)。Acunetix声称这种技术能够发现更多的漏洞并能够精确表明漏洞在代码中的位置,而且误报也会更少。

  一项最近提出的技术试图以更小的侵入性实现类似的效果,它联合使用攻击签名和接口监控来克服渗透测试对注入攻击漏洞测试的局限性。11这是一种黑盒测试技术,因为它只会监控应用程序和漏洞相关资源的接口(如数据库接口)。

  Analysis and Monitoring for Neutralizing SQL-Injection Attacks(Amnesia)工具组合了静态分析和运行时监控来检测SQL注入攻击。12它对Web应用的源码进行静态分析,构建一个由应用生成的合法查询模型。在运行时,它监控动态生成的查询,检查是否与静态生成的模型相符。这个工具认为违反模型的查询为攻击并阻止它访问数据库。

  为了应对Web应用安全的新威胁,开发流程必须也要有所发展。例如,微软安全开发生命周期(Microsoft Security Development Lifecycle)完善了公司的开发流程并特别针对安全问题的解决,例如明确了开发团队的安全培训。13按照微软的说法,这个流程的采用减少了软件中的安全缺陷。尽管这只是一个例子,但是它表明在这个行业中,对软件开发执行安全流程是很重要的事情。

  在整个软件产品的开发和部署生命周期中,开发人员必须要考虑安全性。他们必须要使用安全编码的最佳实践、执行足够的安全测试并使用安全检测系统在运行时保护应用程序。在这个任务中,开发人员需要得到一些帮助来获取需要的技术和能够提高生产率的工具。

  研究人员应该提出创新的工具,能够在开发过程中方便地使用并满足部署时有效性和生产效率的要求。这个演变的中心是安全测试工具,对于检验和确认应用程序以检查安全漏洞来讲,它们是至关重要的。不过,必须要探索新的假设。一个可以预见的可能性就是开发编译器,使其不仅能强制使用最佳编码实现,还能自动化修改存在的安全漏洞。

  参考资料

  1. M. Howard and D.E. Leblanc, Writing Secure Code, Microsoft Press, 2002.
2. C. Ghezzi, M. Jazayeri, and D. Mandrioli, Fundamentals of Software Engineering, Prentice Hall, 2002.
3. G. McGraw, Software Security: Building Security In, Addison-Wesley, 2006.
4. D. Stuttard and M. Pinto, The Web Application Hacker’s Handbook: Discovering and Exploiting Security Flaws, John Wiley & Sons, 2007.
5. B. Arkin, S. Stender, and G. McGraw, "Software Penetration Testing," IEEE Security & Privacy, Jan.-Feb. 2005, pp. 84-87.
6. D.P. Freedman and G.M. Weinberg, Handbook of Walkthroughs, Inspections, and Technical Reviews: Evaluating Programs, Projects, and Products, Dorset House, 2000.
7. N. Ayewah and W. Pugh, "A Report on a Survey and Study of Static Analysis Users," Proc. Workshop Defects in Large Software Systems (DEFECTS 08) ACM, 2008, pp. 1-5.
8. N. Antunes and M. Vieira, "Comparing the Effectiveness of Penetration Testing and Static Code Analysis on the Detection of SQL Injection Vulnerabilities in Web Services," Proc. 15th IEEE Pacific Rim Int’l Symp. Dependable Computing (PRDC 09), IEEE CS, 2009, pp. 301-306.
9. E. Biermann, E. Cloete, and L.M. Venter, "A Comparison of Intrusion Detection Systems," Computers & Security, Dec. 2001, pp. 676-683.
10. I.A. Elia, J. Fonseca, and M. Vieira, "Comparing SQL Injection Detection Tools Using Attack Injection: An Experimental Study," Proc. 21st IEEE Int’l Symp. Software Reliability Eng. (ISSRE 10), IEEE CS, 2010, pp. 289-298.
11. N. Antunes and M. Vieira, "Enhancing Penetration Testing with Attack Signatures and Interface Monitoring for the Detection of Injection Vulnerabilities in Web Services," Proc. IEEE Int’l Conf. Services Computing (SCC 11), IEEE CS, 2011, pp. 104-111.
12. W.G.J. Halfond and A. Orso, "Preventing SQL Injection Attacks Using AMNESIA," Proc. 28th Int’l Conf. Software Eng. (ICSE 06), IEEE CS, 2006, p. 798.
13. M. Howard and S. Lipner, The Security Development Lifecycle, Microsoft Press, 2006.

  关于作者

  Nuno Antunes是葡萄牙科英布拉大学信息科学与技术系的在读博士生,在这里他获得了信息工程的理科硕士。他的研究兴趣包括开发安全Web应用程序和服务的方法论和工具。Antunes是IEEE计算机学会的会员。可以通过nmsa@dei.uc.pt联系他。

  Marco Vieira是葡萄牙科英布拉大学信息科学与技术系的助理教授(assistant professor)。他的研究兴趣包括可靠性和安全基准测试、实验可靠性评估、错误注入、软件开发过程以及软件质量保证。Vieira在科英布拉大学获取了计算机工程的博士学位。他是IEEE计算机学会和ACM的会员。

  Computer是IEEE计算机学会的旗舰出版物,出版了很多为同行热议且广受赞誉的文章。这些文章大都由专家执笔撰写,代表了计算机技术软硬件及最新应用的领先研究。它提供较商业杂志更多的技术内容,而较研究学术期刊具有更多的实践性思想。Computer 传递着可适用于日常工作环境的有用信息。

  查看英文原文:Defending against Web Application Vulnerabilities

  本文最早发表于《Computer》杂志,现在由InfoQ以及IEEE Computer Society合作为你呈现。翻译地址

2013年2月14日星期四

12306反制浏览器被指“傻大黑粗”

  1月28日,已经是2013年春运正式开始的第三天,那寄托着异乡游子急切心情的粉红纸片,依旧一票难求。前两天发生的12306订票助手插件拖垮GitHub事件,风波仍未过去。铁道部为了保证“公平”,他们开始采取技术手段,针对使用插件的浏览器采取反制措施,其结果如何,目前看来,恐怕不能令他们和他们的上峰满意。

  网友码农1999在新浪微吧上发布文章《傻大黑粗+殃及无辜:12306技术反制猎豹浏览器代码级分析》,列出了12306.cn的具体反制措施,其中主要有四种手段。

  手段一: 频繁修改具体功能函数名称,让抢票插件调用失效。

  这是12306开始技术反制时最常用的小技俩。码农都知道,这种“小修小补”的技术屏蔽手段,只要针对12306修改的具体功能函数做修改,即可实现插件正常使用。整个破解及插件更新时间不超过1小时。

  手段二:1月20日开始屏蔽浏览器user agent

  1月20日进入春运购票最高峰(可订2月8日车票),12306使出了屏蔽浏览器user agent的手段,如此一部分没有用抢票版的用户也被屏蔽,一些用户反应未用插件却登陆12306时白屏,进入不到网站。

  针对屏蔽 user agent,只要修改浏览器的用户代理即可实现登陆12306。

  手段三:限制连续2个操作的时间间隔,所有浏览器在未使用抢票插件情况下或无辜中枪。

  如在提交订单时12306判定输入验证码及提交的时间间隔短,即使验证码输入正确,亦会被12306弹出“验证码错误”。此种屏蔽手段造成的后果是:1、抢票插件自动提交订单失效;2、无论使用哪种浏览器的用户,无论使不使用抢票插件,只要“被判定”时间间隔短,即提交订单失败…破解此屏蔽手段,甚至不需要修改插件代码,只需取消抢票插件的“自动提交”功能,手动输入验证码即可。

  手段四:12306后台增加一些逻辑判断,会踢出用插件用户的登录状态。

  这些逻辑判断包括:

  限定操作时间间隔、提交订单时间间隔、查询刷新间隔等。

  这些手段均不能保证只屏蔽抢票插件用户,均有可能让无辜的用户,被12306判定为“插件用户”,不能正常登陆,买不到车票。

  对于这些反制措施,作者认为:

  1. 12306用的那些技术反制手段真心很糙,很临时工。一个词形容:傻大黑粗。
  2. 12306这些小花招,在浏览器厂商面前,效果不大。
  3. 12306的反制措施还带来更大的网站崩溃可能性,殃及无辜。

  文末,作者给12306提出4句话:

  1. 每一个登陆12306的用户,都有权利选择使用的浏览器及正当手段提升使用体验,屏蔽只会加剧无谓的劳动量。
  2. 请不要再聘用实习生或者临时工进行屏蔽抢票插件,请尊重程序猿的智商。
  3. 12306对“无辜”被屏蔽的用户造成极大的不公平。
  4. 12306作为投资5亿的网站,请亮出你技术屏蔽的“杀手锏”。

  在微博评论中,Super_Wang指出:

  用技术手段屏蔽标准http请求。。。无语,只要它没离开http,找出规律也就是个时间问题。对关键请求加单次有效的短信延时二次认证应该是个不错的办法,客户体验就难说了

  执信飘飘想听听其他人的看法:

  大量游戏外挂都不能得到有效解决,何况这是一个甚至没有做验证码适配的脚本程序而已,个人觉得这的确很难做处理。因为不具有很明显的特征性,很难判断。

  来源:InfoQ投稿,原文链接

12306订票助手插件拖垮GitHub事件始末

  春节临近,12306订票难的问题再一次被引向风口浪尖。而这一次,各家浏览器厂商不失时机的推出了“春节专版”。这些林林总总浏览器的共同特点,是集成了一位网友iFish(木鱼)的“订票助手”插件。

  不凑巧的是,这个插件的早期版本使用GitHub的Raw File服务作为CDN,并对返回403错误代码的请求使用非常暴力的5秒重试。于是,在1月15日的时候,第一个订票小高峰到来的时候,GitHub被间接的DDos。

  GitHub的运维工程师Jesse Newland在发现服务器负载异常之后,不得不禁用了这个代码所在Repo的Raw服务,并在Repo里报告了一个issue —— 他发现12306引用了这个Repo里的一个资源,由于访问量巨大,这个资源对GitHub的服务产生了负面的影响,希望有人可以联系到12306的工程师去除这个引用。

  身在大洋彼岸的GitHub工程师在解决了GitHub的服务问题之余,显然不太清楚中国的两点情况:

  1. 春运是什么,12306是什么
  2. 12306的工程师是不可能被联系到的

  大家疑问

  大家的质疑,存在于两点:

  1. 为什么一个浏览器插件需要从GitHub引用资源?
  2. GitHub的负载能力这么弱吗?

  疑难解释

  第一个问题,还是让插件作者木鱼自己来解释:

  引入自动更新。

  由于12306订票助手是个很特殊的东西,依赖于铁道部的网站而存,并且其运行极度依赖网站本身的功能以及页面结构,所以随着铁道部的改进,很容易失效(虽然他们的前台样子从开始到现在,一年多了几乎就没变过……他喵的为什么我又要用年做单位说时间,真伤心)。因此为了保证功能的正常,订票助手在很早的版本开始就引入了自动更新机制(1.4开始)。最开始的更新都是放在自己网站上的,并且区分了Firefox和Chrome。

  最初的助手是以UserScript的模式出现的,调试在Firefox下调试。在Firefox下时,Scriptish提供了支持跨域的GMxmlHttpRequest功能,可以直接用ajax访问我的网站。但是在Chrome下,则没有这样的便利,不支持跨域ajax,所以用的是引入script脚本的方式检测更新。在后来Firefox和Chrome分支完全合并后(最开始针对不同的浏览器分离的,后来发现同步实在太麻烦了),舍弃了一些特异的功能(如GMxmlHttpRequest),为一些功能做了适配(如桌面通知),更新也就用下来了。

  但是后来不知道什么时候开始,这个更新机制突然失效了。为啥呢,这要从另一件事开始说起。

  那就是12306的HTTPS。

  作为一个日点击14亿的网站,网宿科技的CDN还是很给力的,根据我收集到的资料,其加速节点上百个。但是,作为一个订票的网站又要CDN的,为什么会用HTTPS协议还是一个自签发的根证书,实在太让人费解。任何一个了解网络知识的人都知道,HTTPS协议下服务器的负载能力要比HTTP的低很多,何况订票又不是什么机密的数据。 总会有人跳脚出来说订票啊多机密,我总是很反对,哪门机密了,车次还是余票数据?

  这个HTTPS带来了很大的麻烦。

  不知道哪个版本Chrome引入的安全机制,对于一个HTTPS网站,其所有引用的资源(Script和StyleSheet之类的),也必须位于HTTPS的服务器上,否则拒绝执行。而我并没有HTTPS服务器,因此,Chrome下自动更新华丽地挂了。 然后是Firefox。Firefox下播放不了音乐,我一直以为是Firefox不支持,后来才发现是Firefox的安全机制在作怪:HTTPS的网页拒绝播放来自于HTTP的多媒体文件。 这俩奇葩让我伤透了脑筋。然后无意中瞥见GitHub竟然是HTTPS的,So…… 转移过去,变成了顺理成章的事情,我求爹爹告奶奶没求来一台HTTPS的服务器,虽说有免费的SSL证书什么的但是我去申请的时候,连那提供商的网站自己都证书错误了。

  于是事情都解决。

  而第二个问题,GitHub的负载能力为什么这么弱,原因在于GitHub根本不适合作为CDN服务。著名博客比特客栈的文艺复兴,对此做了详细解释:

  1.   它并非静态文件服务器,换句话说,所有请求访问都要先经过一堆服务器代码处理,降低了它的响应速度。

  2.   它返回的MIME与文件无关(永远是text/plain),某些浏览器,例如说IE,不会执行MIME类型错误的javascript文件。

  3.   它返回的Cache-Control Header不允许浏览器缓存文件,等于失去了CDN最基本的功能。 恰恰因为12306订票助手不运行于IE,也不希望更新文件被缓存,Raw file的后两个劣势才没有显现出来。但剩下的那个劣势,却让Github的响应速度大打折扣,不得不暂时封锁Raw file访问。

  针对这个问题,原文作者直中要害的提供了两个层面的解决方案:

  • 使用GitHub作为CDN的正确之道:

  那么,Github作为CDN的正道是什么?Github Pages。通过加入gh-pages branch,你可以修改和发布自己repo的文件。值得提醒,Pages虽然免费,并非资源无限,详见官方Disk Quota的描述——“虽然我们没设上限,但请各位合理使用。”

  Github轻描淡写的说合理使用,而不是严明规章到MB、GB,其实是一种潜意识的相互信任。这是一种在贫富悬殊供求关系紧张的中国日益缺少的东西,12306订票助手的存在就是一种印证:乘客不相信12306,12306不相信乘客,最后逼出一个12306订票助手,每天乃至每半天更新一次来满足中国人订票回家的需求。

  • HTTPS下如何引用HTTP资源:

  请问Google Reader,是怎么在HTTPS域下播放优酷与土豆等非HTTPS的视频?我们在去年9月发现了同样的问题,Google自己是这样解决的——

  Chrome 21之后,在SSL加密页面embed非SSL的Flash会怎样呢?会被默默的屏蔽掉,只留下一句console报告。那Google Reader是怎么绕过这个问题看优酷与土豆视频的?他们iframe了一个非SSL页面,再在里面引用flash(引用页连域名都是不同的)

  同理也适用于Javascript,这也是12306订票助手当前的解决办法(Firefox除外)。不再需要SSL下的CDN了。

  不是结束

  订票助手的作者木鱼,不堪忍受各界观光团纷纷造访他本开源在GitHub上的订票助手代码仓库,最终删除了项目。但他表示仍将继续精简/改进这款订票插件。

  因为这个插件,铁道部甚至投诉至工信部,要求其责令各家浏览器提供商停止提供附带抢票功能的浏览器的下载。不过就本文发表前,各家浏览器厂商均表示尚未接到相关通知。

  这一切还都不是结束。

  来源:InfoQ投稿,原文链接

2013年2月7日星期四

苹果发表声明强烈建议用户不要越狱

  苹果发表声明,强烈建议用户“不要越狱”,苹果称用户越狱除了会使手机不再享有苹果的任何保修服务外,也会带来以下问题:设备会经常遇到崩溃问题,出现安全漏洞,电池寿命缩短,资料丢失,影响到未来的系统更新等。

  声明全文如下:

  iOS 与 iPhone、iPad 和 iPod touch 经由 Apple 设计,旨在互相搭配稳定工作。未经授权修改 iOS(“越狱”)可导致遭破解的 iPhone、iPad 或 iPod touch 出现很多问题。未经授权修改 iOS 导致的问题示例包括下列各项:

  不稳定:设备频繁死机和意外死机、内建 app 和第三方 app 崩溃和卡死以及数据丢失。

  安全漏洞:此类修改已导致安全性降低,从而便于黑客窃取个人信息、破坏设备、攻击无线网络或者引入恶意软件或病毒。

  电池续航时间缩短:遭破解的软件已导致电池电量加速耗尽,从而缩短了 iPhone、iPad 或 iPod touch 单次电池充电后的操作时间。

  语音和数据不稳定:通话中断、速度很慢或数据连接不可靠,以及位置数据延迟或不准确。

  服务中断:设备上的 Visual Voicemail、天气、股票等服务已中断或不再正常工作。此外,使用 Apple 推送通知服务的第三方 app 接收通知时遇到困难,或收到发往其他破解设备的通知。iCloud 和 Exchange 等其他基于推送的服务与其相应的服务器同步数据时出现问题。

  无法应用日后的软件更新:部分未经授权的修改已导致 iOS 出现无法修复的损坏。日后安装 Apple 提供的 iOS 更新后,可导致遭破解的 iPhone、iPad 或 iPod touch 永久无法操作。

  Apple 强烈警告不要安装任何破解 iOS 的软件。请注意未经授权修改 iOS 违反 iOS 最终用户许可协议,因此 Apple 有权拒绝向已安装任何未经授权软件的 iPhone、iPad 或 iPod touch 提供服务,这点也很重要。

2013年2月5日星期二

中国电信承诺停止推送宽带广告

  针对用户投诉的“中国电信宽带出现强制推送广告”现象,中国电信通过其官方微博回应称,“发现个别下属单位确有此类问题,已经采取措施停止向宽带用户推送第三方广告”。

  据悉,一些省市的地方运营商等利用宽带服务向用户推送强制性广告投机“盈利”,大大影响了用户对宽带服务的感知度,导致用户投诉量增加。用户的投诉对象主要是打着“电信ADSL弹窗广告的独家代理商”旗号的广告公司。同时,也有软件厂商针锋相对地推出所谓屏蔽电信推送式广告的“安全浏览器”,从而衍生出另外一个市场。如此乱象,显示了国内市场对宽带推送广告问题的监管机制不完善,给广告商甚至不法分子提供了可乘之机。对此,中国电信集团公司表示禁止再推送这种广告。

  据了解,目前国内的宽带服务商主要是中国电信与中国联通两大运营商,还有一些运营商通过租借运营商基础设施向用户提供宽带服务。

  以下为中国电信客服官方微博的全文:

  近期有网友通过微博向我们反映在宽带使用过程中被强制推送广告。中国电信对此十分重视并迅速排查,发现个别下属单位确有此类问题,对此我们深表歉意。目前我们已采取措施停止了向宽带用户推送第三方广告。真诚感谢您的关注与监督,欢迎网友通过各种方式向我们提出宝贵意见,以便我们更好地为您提供服务。

2013年2月4日星期一

Twitter遭黑客攻击25万账号泄密

  全球知名的社交网络及微博客服务网站Twitter日前宣布,该网站遭到黑客攻击,导致约25万账户信息被盗,其中包括用户姓名、电子邮箱、加密的密码。

  Twitter表示已经对这些被盗账户进行了密码重置,新密码已经被发送到了用户邮箱中。Twitter强调,被盗取的账户在Twitter所有账户中只占到很小比例,Twitter在全球大约有2亿活跃用户。

  一名专家表示,Twitter这次被攻击,可能是一名员工的家用或工作电脑首先被攻破,被利用的漏洞是Java不久前被曝光的漏洞。

  对于这一次被攻击,Twitter公司表示这绝不是有人为了恶作剧而与Twitter开的小玩笑。Twitter在随后的一份声明中提到:“这绝不会是业余人士做的,我们相信它绝对不会是一次孤立的事件,在它背后一定有一个专业的黑客团队,估计除了我们,近期内还会有一些其他的公司遭到他们的攻击。出于这个原因我们认为Twitter有必要向大家发出提示,并帮助政府和相关机构一起将这些攻击者绳之于法,为互联网用户提供一个更加安全可靠的网络环境。”

Twitter遭黑客攻击25万账号泄密

  虽然被攻击的Twitter帐号只占总共帐号的一小部分,但是我表示自己的Twitter也在被盗的行列中,不幸中枪,2月2日,我的信箱收到重置密码的邮件,旧密码无法登录,通过邮件里的链接地址可以直接修改新密码。

  根据微博上的反馈,包括和菜头等不少中文Twitter帐号都遭到了攻击,莫非这次黑客攻击是针对中文Twitter帐号的?

谷歌街景地图拍摄更衣室照片

  谷歌街景地图又立功了,这次拍摄到的照片令人震惊,在法国布里昂松的一家店叫Krakatoa体育用品商店的更衣室里,赫然站着一对正在做爱的男女。从照片上看,两人的衣裤都脱到了脚踝。

  谷歌去年9月增加室内街景地图,可以看到很多商家室内的照片。对于商家来说,得到了更多曝光机会,而对于用户来说,这个功能也相当实用,他们可以在进店前先看到店铺内部模样。

  目前室内街景地图已经覆盖了美国、澳大利亚、新西兰、法国、以色列、荷兰、加拿大和英国的一些城市,商家可以雇佣经过Google认证的摄影师对自己的店拍摄360度全景图。

谷歌街景地图拍摄更衣室

  该街景地址地址:点击这里