放翁(文初)的一亩三分地

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  210 随笔 :: 1 文章 :: 320 评论 :: 0 Trackbacks

    应该是去年的年初,我受到普元公司的邀请去参加了一次SCA、SOA的技术交流会,当时也是自己第一次去和那么多陌生的朋友交流技术心得,同时也被普元公司的这种纯技术性的交流方式所打动,也在想哪一天阿里巴巴也能够举办一次这样的小规模有针对性地技术交流会那会让我们这些技术人员收益菲浅。一年后的今天,当老大问我有个这样的会议是否要参加的时候,自己毫不犹豫地报了名,虽然看起来和自己专注的工作不是很相关,但是还是那个想法:首先不了解是无法知道是否和自己相关与否,其次就算不相关,多学多听,触类旁通的技术延展只会给自己带来更多的想象空间和创新思维。

    按照会议安排,早晨有两个讲座,下午有四个讲座,每个讲座1个小时左右。第一个出场的是腾讯的安全中心总监杨勇,整个演讲很轻松,首先是对腾讯的整体产品结构和背景作了一下阐述,然后就从安全中心这个整体来讲述安全对于腾讯的意义,如何实施以及一些流程的制定。没有过多的牵涉安全问题的细节,着重是讲述了安全中心面临的四个方面的问题,以及通过什么手段去解决。这其实和他本身所处的工作职责来说相符合,如果仅仅只是来讲某一个安全技术应用,那么就有些太过狭隘了。不过在提问的时候一个问题的回答让我还是留有一些印象的,主持人收集到一个问题:“腾迅安全中心的建设初期遇到的最迫切需要解决的问题是什么?”,他回答道:“其实腾讯安全中心从建设初期到现在一直面临各种迫切的问题,只是随着时间的不同而不同的演变,最早的协议安全到客户端安全到奥运期间的信息安全都是一个发展的阶段”(因为没有ppt以及记录,因此描述的可能不太准确)。但是这个思想任何技术行业都是一样的,时代不同关注不同,需要解决的问题也是在发展的。

   第二个议题是Discuz的剑心带来的“web应用程序中的字符集攻击”,这个演讲就相对来说比较注重专业细节方面的阐述。作为互联网应用开发者,使用Java的人第一堂课就是中文乱码,很多人只看到如何去配置或者写一点转换语句就可以解决,但是对于编码方式就不求甚解,ISO-8859-1,GB2312,UTF-8,UTF-16区别是什么,为什么会引起乱码。其实了解了编码的原理就很能够解释如何会产生乱码,同时产生乱码的时候也可以根据乱码的情况了解可能是因为什么编码转化造成的(阿里巴巴的宝宝写了一篇很详细的文章说了这个问题,进入公司以后我也是看了那片文章才系统地对编码方式做了完整的了解,以前都是碎片)。不过今天听了这个演讲,到让我知道了原来编码方式也被人用来攻击。其实基本的思想主要就是一点:由于信息转发中对于不同编码解析的方式不同或者是过滤不同,导致出现一些漏洞。通俗的比喻就是刺杀秦始皇的图穷匕见,侍卫就好比第一层把关的信息转发者认为着幅图没有威胁,但是真的按照刺客的处理方式那么就是一个最好的攻击性工具。记得我在和同事探讨REST对于Http协议的使用时说最重要的就是REST不再使用Http协议作为传输承载协议而是作为业务协议,那么解析业务的时候究竟是分析协议中指定的编码方式还是内容中的编码方式,结果会大不一样,同时作为安全人员的角度来看,这也会存在一种安全隐患。所以其实任何一种错误都可以被利用作为攻击的手段。

    下午的议题一共有四个,虽然时间比较长一直连续讲到6点多,但是就像主持人讲的,每一个人都“坚持”下来了,呵呵,当然坚持并不是因为不好听,而是做在那儿听比写代码要累很多,当然讲课的同学们也是十分辛苦的。下午第一个演讲的是team509的创始人吴石,讲的主题是“部分软件安全的思考”,内容专业化很强,对很多比较底层的安全问题(操作系统等)作了一些介绍,当然对于我这个门外汉只能听懂个大概意思,不过还是有所了解那些名词的意思到底是什么。第二个是微软的大牛蛙同学,也是安全领域专家讲述了一下微软的SDL(Security Development Lifecycle),望名生意,安全实施的流程化。第三个演讲是两位同学做的,也是我下午听得比较有感触地,先是网名余弦(钟晨鸣)北京知道创宇信息技术公司的安全研究员,讲的是CSRF蠕虫技术,从一个黑客的角度来阐述CSRF的原理以及危害性。这部分比较技术化一些,但是由于和我关注的Web安全也比较相关一些,所以听起来也不是比较迷糊。虽然听着他讲CSRF,但是其实我脑子里面已经在考虑关于Open API的一些安全问题。其实在阿里软件承载淘宝的API过程中,对于客户端的安全问题就一直都在谈,但是对于SIP来说总是鞭长莫及,因为服务集成平台只会保障ISV和ISP之间的信息交互的真实性,但是用户是否由于ISV的技术问题导致信息伪造提交,那么就不得而知,但是最后表现出来的结果就是ISP的Open API计划为ISP带来了更多的安全隐患,也就是说原来淘宝一家漏洞,以后可能会是千千万万家ISV的漏洞,其实这也是上面几个演讲提到的合作风险问题,第三方的技术能力不得而知,同时产生的风险也会很难控制。其实从这里也多多少少看出来为什么FaceBook,myspace,最早对于用户安全隐私数据的开放不仅仅是开放了数据API,同时也会有整一套上层框架支持,其实也是出于开发者能力不足引起隐私数据被恶意修改而作的防护措施。那么现在Open 用户的数据特别是以后涉及到金额的api如何保证isv不欺诈,isv不被欺骗,这可能是后续需要更加重视的问题。同时,在听了CSRF的攻击中谈到的对于资源定位猜测以及操作的时候,让我对REST的风格又打了一个冷颤,REST对于资源的规划和定位十分容易,但是这也为这类攻击提供了便利,同时对于资源操作依赖于Http协议,也会让资源的安全性打了折扣,这需要对Open API开发人员做更多的安全工作指导,或者提供安全框架来防范Open API可能会产生的安全漏洞。紧接着后面的演讲是北京知道创宇信息技术公司的创始人赵伟,应该是业界比较资深的专家了,本来的议题是“恶意网站检测”,不过他还是讲了他这些年来的一些经历以及安全领域的黑色产业链的问题。平时这方面关注的不多,不过今天这一番交流,让我对安全领域的发展以及现况有所了解,甚至有时候就觉得现在上网就算装了一大堆东西还是感觉在“裸奔”。最后一个议题是51.com的郑歆炜讲的“运维安全经验谈”,总结了运维所面对的问题以及解决方案,协调,沟通,总结,知识库,其实这些对于开发人员来说何尝不是呢。最后小黑作了一个简短的总结,同时预报了明天他会做一次附加的构建安全Web架构的讲座,期待明天半天的研讨会和附加讲座。

    好久没有踏踏实实地坐着好好听课了,这次一天半的学习对于自己来说也算是一次新知识的扫盲,同时也为自己后续的工作可能存在的问题或者可以借鉴的知识作一个铺垫。

posted on 2008-12-17 22:32 岑文初 阅读(1834) 评论(1)  编辑  收藏

评论

# re: 精武门之Web安全研讨会首日感受 2008-12-18 04:38 heyang
牛人不少。  回复  更多评论
  


只有注册用户登录后才能发表评论。


网站导航: