PHP and the OWASP十大安全漏洞

The Open Web Application Security Project released a helpful document that lists what they think are the top ten security vulnerabilities in web applications.

These vulnerabilities can, of course, exist in PHP applications. Here are some tips on how to avoid them. I’ve included related links and references where relevant.

1. Unvalidated Parameters

Most importantly, turn off register_globals. This configuration setting defaults to off in PHP 4.2.0 and later. Access values from URLs, forms, and cookies through the superglobal arrays $_GET, $_POST, and $_COOKIE.

Before you use values from the superglobal arrays, validate them to make sure they don’t contain unexpected input. If you know what type of value you are expecting, make sure what you’ve got conforms to an expected format. For example, if you’re expecting a US ZIP Code, make sure your value is either five digits or five digits, a hyphen, and four more digits (ZIP+4). Often, regular expressions are the easiest way to validate data:

if (preg_match('/^d{5}(-d{4})?$/',$_GET['zip'])) {
    $zip = $_GET['zip'];
} else {
    die('Invalid ZIP Code format.');
}
  

If you’re expecting to receive data in a cookie or a hidden form field that you’ve previously sent to a client, make sure it hasn’t been tampered with by sending a hash of the data and a secret word along with the data. Put the hash in a hidden form field (or in the cookie) along with the data. When you receive the data and the hash, re-hash the data and make sure the new hash matches the old one:

// sending the cookie
$secret_word = 'gargamel';
$id = 123745323;
$hash = md5($secret_word.$id);
setcookie('id',$id.'-'.$hash);

// receiving and verifying the cookie
list($cookie_id,$cookie_hash) = explode('-',$_COOKIE['id']);
if (md5($secret_word.$cookie_id) == $cookie_hash) {
    $id = $cookie_id;
} else {
    die('Invalid cookie.');
}

If a user has changed the ID value in the cookie, the hashes won’t match. The success of this method obviously depends on keeping $secret_word secret, so put it in a file that can’t be read by just anybody and change it periodically. (But remember, when you change it, old hashes that might be lying around in cookies will no longer be valid.)

See Also:

  • PHP Manual: Using Register Globals
  • PHP Cookbook: Recipe 9.7 ("Securing PHP’s Form Processing"), Recipe 14.3 ("Verifying Data with Hashes")

2. Broken Access Control

Instead of rolling your own access control solution, use PEAR modules. Auth does cookie-based authentication for you and Auth_HTTP does browser-based authentication.

See Also:

3. Broken Account and Session Management

Use PHP’s built-in session management functions for secure, standardized session management. However, be careful how your server is configured to store session information. For example, if session contents are stored as world-readable files in /tmp, then any user that logs into the server can see the contents of all the sessions. Store the sessions in a database or in a part of the file system that only trusted users can access.

To prevent network sniffers from scooping up session IDs, session-specific traffic should be sent over SSL. You don’t need to do anything special to PHP when you’re using an SSL connection, but you do need to specially configure your webserver.

See Also:

  • PHP Manual: Session handling functions
  • PHP Cookbook: Recipe 8.5 ("Using Session Tracking"), Recipe 8.6 ("Storing Sessions in a Database")

4. Cross-Site Scripting (XSS) Flaws

Never display any information coming from outside your program without filtering it first. Filter variables before including them in hidden form fields, in query strings, or just plain page output.

PHP gives you plenty of tools to filter untrusted data:

  • htmlspecialchars() turns & > " < into their HTML-entity equivalents and can also convert single quotes by passing ENT_QUOTES as a second argument.

  • strtr() filters any characters you’d like. Pass strtr() an array of characters and their replacements. To change ( and ) into their entity equivalents, which is recommended to prevent XSS attacks, do:
    $safer = strtr($untrusted, array('(' => '(', ')' => ')'));

  • strip_tags() removes HTML and PHP tags from a string.

  • utf8_decode() converts the ISO-8859-1 characters in a string encoded with the Unicode UTF-8 encoding to single-byte ASCII characters. Sometimes cross-site scripting attackers attempt to hide their attacks in Unicode encoding. You can use utf8_decode() to peel off that encoding.

See Also:

5. Buffer Overflows

You can’t allocate memory at runtime in PHP and their are no pointers like in C so your PHP code, however sloppy it may be, won’t have any buffer overflows. What you do have to watch out for, however, are buffer overflows in PHP itself (and its extensions.) Subscribe to the php-announce mailing list to keep abreast of patches and new releases.

See Also:

6. Command Injection Flaws

Cross-site scripting flaws happen when you display unfiltered, unescaped malicious content to a user’s browser. Command injection flaws happen when you pass unfiltered, unescaped malicious commands to an external process or database. To prevent command injection flaws, in addition to validating input, always escape user input before passing it to an external process or database.

If you’re passing user input to a shell (via a command like exec(), system(), or the backtick operator), first, ask yourself if you really need to. Most file operations can be performed with native PHP functions. If you absolutely, positively need to run an external program whose name or arguments come from untrusted input, escape program names with escapeshellcmd() and arguments with escapeshellarg().

Before executing an external program or opening an external file, you should also canonicalize its pathname with realpath(). This expands all symbolic links, translates . (current directory) .. (parent directory), and removes duplicate directory separators. Once a pathname is canonicalized you can test it to make sure it meets certain criteria, like being beneath the web server document root or in a user’s home directory.

If you’re passing user input to a SQL query, escape the input with addslashes() before putting it into the query. If you’re using MySQL, escape strings with mysql_real_escape_string() (or mysql_escape_string() for PHP versions before 4.3.0). If you’re using the PEAR DB database abstraction layer, you can use the DB::quote() method or use a query placeholder like ?, which automatically escapes the value that replaces the placeholder.

See Also:

7. Error Handling Problems

If users (and attackers) can see the raw error messages returned from PHP, your database, or external programs, they can make educated guesses about how your system is organized and what software you use. These educated guesses make it easier for attackers to break into your system. Error messages shouldn’t contain any descriptive system information. Tell PHP to put error messages in your server’s error log instead of displaying them to a user with these configuration directives:

log_errors = On
display_errors = Off

See Also:

8. Insecure Use of Cryptography

The mcrypt extension provides a standardized interface to many popular cryptographic algorithms. Use mcrypt instead of rolling your own encryption scheme. Also, be careful about where (if anywhere) you store encryption keys. The strongest algorithm in the world is pointless if an attacker can easily obtain a key for decryption. If you need to store keys at all, store them apart from encrypted data. Better yet, don’t store the keys and prompt users to enter them when something needs to be decrypted. (Of course, if you’re prompting a user over the web for sensitive information like an encryption key, that prompt and the user’s reply should be passed over SSL.)

See Also:

9. Remote Administration Flaws

When possible, run remote administration tools over an SSL connection to prevent sniffing of passwords and content. If you’ve installed third-party software that has a remote administration component, change the default administrative user names and passwords. Change the default administrative URL as well, if possible. Running administrative tools on a different web server than the public web server that the administrative tool administrates can be a good idea as well.

10. Web and Application Server Misconfiguration

Keep on top of PHP patches and security problems by subscribing to the php-announce mailing list. Stay away from the automatic PHP source display handler (AddType application/x-httpd-php-source .phps), since it lets attackers look at your code. Of the two sample php.ini files distributed with PHP ( php.ini-dist and php.ini-recommended), use php.ini-recommended as a base for your site configuration.

See Also:

操作系统使用空密码也ok拉

假设你的XP操作系统上有两个用户帐号:一个每天都使用的帐号,设置为限制用户(Limited User),另一个帐号设置在管理员组(Administrator Group),用作系统维护。你的电脑放在一个安全的地方,你是唯一可以物理上接触这台机器的人。下面两种选择,哪种更安全呢?

  • 你给管理员账户设置一个空密码;
  • 你为管理员账户设置了一个15位字符的强密码,使用随即生成的字符串,数字和符号。

你相不相信,空密码在很大程度上提供了更多的保护。因为在Windows XP操作系统中引入的加强安全机制,空密码的账户只能被用作直接登陆,要么在欢迎界面或者Windows的登陆对话框。你无法通过远程桌面登陆没有密码的账户,你也无法使用Run As功能来进入账户。想要入侵你机器的攻击者也无法通过网络获取管理员访问权限。

但是注意了,这个办法不是适合于每个人的。别在移动笔记本上使用这个办法(因为你的电脑一旦离开你,谁都可以看你里面的机密资料了),也别在加入Windows域的电脑上设置空密码,或者你真的需要远程桌面访问也别用这个办法。

但是这个机制对于家用电脑真的是非常好,特别是给老人和小孩用,再合适不过了,既简单又安全。

Original Post By Ed Bott

2006信息安全审计、控制与治理圆桌会议

昨天在上海的城市规划馆市府发言厅举办了Future S中国IT管理论坛R8,主题就是Control,Audit和Governance。与会的有IBM,AVOCENT,SYMANTEC,JUNIPER,BEARPOINT和DELOITTE的嘉宾,以及上海市信息中心的主任。

  市信息中心主任致开幕词

  各位业界的专家坐在一起讨论SOX法案对CSO的启示

一整天的演讲,除了Avocent公司介绍KVM产品和主题没有多大关系,有商业广告的嫌疑,其他各厂商的演讲都极力避免产品的介绍,公司的介绍,而更多的是对信息安全的讨论。

Juniper的中国区市场经理的讲演Slide竟然和前天下午在锦沧文华的Roadshow上的产品介绍一摸一样,不过由他来讲,却换作另一个角度,完全的信息安全理念的宣传,不参杂产品介绍的内容,实在难得,令人佩服。

相比之下,Symantec的产品专家就显得经验明显不足,话语没有说服力,几乎可以忽略不计。

IBM的安全顾问则显示出大公司的气魄和长期从事安全顾问工作的丰富经验,给听众带来比较多的经验的分享,思路清晰,表达明确,还得到了最佳人气奖。

同样的,毕博咨询和德勤作为专业的审计咨询公司,面对这种场合,可以说是侃侃而谈,而且德勤的合伙人对SOX以及相关的法律规章制度的了解,让人深感佩服。

会议讨论的主题就是SOX法案对企业的影响,而我也从此次圆桌会议更深切的领会和理解了SOX法案的内涵,以及如何比较好的来进行实践,满足SOX法案的要求。

我个人认为最深刻的就是要解决IT部门和企业业务部门的关系。到底是IT部门仅仅作为服务基础部门受制于财务销售等业务部门,还是IT部门凌驾于各业务部门之上,对各业务部门的信息使用指手画脚?IT部门的地位和重要性不言而喻,但是要真正做到IT有效的成为企业生存的核心,需要公司的最高层的认可和重视,这样IT部门才能够成为企业对于IT决策的实施部门,而不是被动的日常维护部门。

这样的高层对话和讨论对于中国的信息安全发展有非常好的指引作用。参加会议的有很多国有企业,垄断企业的IT高层,对他们进行洗脑和灌输,不仅可以让他们转变陈旧的思想,也可以加快信息安全在国内的发展。

Cisco VPN 集中器存在IKE资源耗尽型DOS攻击威胁

http://www.nta-monitor.com/posts/2006/07/cisco-concentrator-dos.html

概述

NTA Monitor 在Cisco VPN 3000系列集中器产品中发现拒绝服务攻击的漏洞。这个漏洞影响IKE协议协商的第一阶段。UDP或者TCP传输的Main模式或者Aggressive模式都受到影响。

利用这个漏洞,攻击者可以发送大量IKE请求使得VPN集中器的IKE资源耗尽达,这会阻止其他正常客户无法连接VPN或者使交换密钥失败甚至无法继续使用,以达到DOS目的。这个攻击不需要高带宽,区区一个攻击者就可以攻陷多个VPN集中器。这个漏洞背后的机制和著名的TCP SYN FLOOD漏洞是类似的。

漏洞细节

这个漏洞允许攻击者向远程的VPN集中器发起大量新的IKE session,并快于集中器队列中这些无效session超时的速度,使得VPN集中器的队列越积越多并且资源耗尽。

这个攻击通过发送IKE阶段一数据包可以接受的一种传输格式。不需要合法的身份就可以攻击此漏洞,因为这个漏洞发送在身份认证之前。这漏洞同时影响Main模式和Aggressive模式,包括upd和tcp封装的ike协议。

为了攻击这个漏洞,攻击者需要以超过VPN集中器IKE session超时的速率发送IKE数据包。测试者发现目标集中器一般在每秒2个包的速率就开始受到影响了,当速度达到每秒10个包的时候设备就不可用了。以Main模式最小的数据包来计算,单个传输112字节,每秒十个包相当于9kbps。

 VPN集中器在这些攻击数据包持续攻击的情况下无法继续处理IKE的请求,但是一旦攻击数据包停止,集中器就会回归到正常状态并处理列队中残留的会话请求。

同时,不太可能阻止外部向VPN集中器发起的IKE服务连接,因为远程的ipsec访问需要。IKE通常使用Udp传输协议,攻击者可以伪造数据包的源ip来躲过ip地址过滤。而且,IDS/IPS系统也可能很难检测到此类攻击,因为这些数据包都是合法的IKE数据包。

攻击症状是目标集中器一旦协商堆栈被挤满就不再响应IKE请求。这就意味着新的客户端将无法连接,第一阶段的密钥重协商将会失败。还不知道第二阶段的密钥协商是否会受到影响。已经建立的VPN隧道上跑的流量不会受到影响,除非它们再次协商密钥。

Cisco的反映

http://www.cisco.com/en/US/tech/tk583/tk372/tsd_technology_security_response09186a00806f33d4.html

现在仍然没有什么好的解决办法。

评论

这个漏洞不仅仅是Cisco VPN设备一家的产品问题,这个漏洞很可能影响到所有使用IKE version1标准的所有VPN产品。这个漏洞是属于协议类型的缺陷,类似于TCP的SYN Flood弱点一样。但是这个攻击这个漏洞比SYN flood更容易实现,而不像SYN Flood需要大量的数据包和带宽占用,仅用一点点流量就可以对提供VPN服务的设备造成致命性的DOS攻击。在目前没有什么很好的解决办法的情况下,是不是各VPN解决提供商能够考虑将使用的IKE协议升级到高版本?也许DOS和DDOS将一直伴随着互联网发展下去,永远是个让所有人头疼的问题,也是让安全业界得以生存的因素吧。

Blog程序WordPress v2.03及以下版本存在严重安全漏洞

是的,这意味着在2.0.4版本还没有发布之前,目前的所有版本都存在此严重安全漏洞。

目前发现的漏洞直接影响Wordpress的2.03及以下版本(包括1.5.x),此漏洞会造成任何已注册的评论者以Guest身份对系统造成严重的破坏。

如果你在用Wordpress的话,建议立即在option菜单中禁用“Anyone Can Register”选项。

同时也建议删除那些并没有发表评论却又成为subscriber(Guest)的用户,或者删除那些你并不认识的用户。

WordPress开发团队已经注意到此问题并希望能够尽快发布2.0.4版本来修复此安全漏洞。

Leaving it open and letting people sign-up for guest accounts on your WordPress blog could lead to incredibly nasty stuff happening if anybody so desired. And trust me I am not exaggerating this. So don’t wait a second to disable this option and please relay the message.

WordPress dev team has been notified a while back and I dare hope they will soon start acting on it, if only by relaying a similar announcement through the official channel (as well as, of course, releasing a proper patch).

消息来源:Dr Dave

利用Google来攻击数据库

这个概念并不新:使用Google或其他搜索引擎来寻找存在漏洞的系统并攻击他们。但是看上去不同的情况是这样的攻击手段在最近几个月呈直线上升的态势。这不由让所有人都感到吃惊。
搜索引擎尽职的干它们的活,它们索引每个连接在因特网上的站点。它们揭示并报告每个站点的好东西,同时也包括坏东西,当然是不经过任何过滤的。而我们要做的仅仅是在搜索引擎上键入适当的查询语句并得到我们想要的信息。黑客们也利用Google等搜索引擎进行这些查询,只不过他们利用bots或者其他程序让他们整日整夜的进行。第二天当他们醒来时,一串漂亮的存在漏洞的列表就展现在他们面前,接下去就是等待被他们攻击。
Google也常被用作渗透性测试的必备工具。因为Google包含了各种各样的信息,而Google自己并不会撒谎,它展示的都是网路上暴露的真实的信息,只不过人们并没有意识到Google搜索引擎有多么强大的威力,并没有好好去挖掘其中的数据。
利用Google,我们或许会找到一些并没有安全保护的网络节点,利用它们,我们可以控制许多不同的设备,比如网络打印机、PBX、企业电话系统、路由器、网络摄像头,当然还有网站本身。这些都可以被Google找到。但是把Google作为有效的黑客工具的好处并不仅限于此,它还可以被黑客作为某种代理服务。 虽然常见的一些安全工具软件可以帮助攻击者来扫描并分析出一个公司的网络结构,但是有了Google,攻击者就可以完全让Google来完成这些工作。这样不仅避开了探路的风险,而且这些信息搜集的过程很难被系统管理员发现和阻止。用Google可以查询一些网站的站点拓扑结构,并通过一些附加信息的补充,黑客们是很容易勾勒出公司网络的真实拓扑的。
通过使用预先设计好的Google查询语句和文本处理工具就可以得到SQL数据库的密码甚至错误信息。然后可以利用这些信息来进行SQL的注入攻击。这就让Google真正成为了黑客工具。
虽然Google并不是很在意存储的海量的数据自身存在的安全隐患,同时Google也表示为了保证信息的客观公正,Google并不会去过滤一些所谓的敏感信息。但是事实上Google已经在不经意中帮助了一些蠕虫的攻击和数据库的侵入,因此搜索引擎已经因为安全原因拒绝了一些恶意的查询。

电话银行的安全性有待加强

当人们更多的关注网上银行的安全性问题,热衷于谈及如何预防网银失窃、网络诈骗等事件的时候,我们却忽视了电话银行存在的各种更严重的安全性问题。
使用网银的人都知道,开通网上银行需要下载电子证书或者个人USB棒等移动个人证书,访问网银站点时也是使用SSL加密的页面进行访问,有些银行甚至做了瘦客户端来加强客户访问的安全性。这些通讯加密、双向认证的措施,都保证了在线银行业务操作时的数据保密性和完整性。在这种模式下,要进行man-in-middle的攻击是很难的。常见的网银被盗都是由木马后门或者更有效的钓鱼网站以及社会工程学来实现的。而直接的对客户访问网银进行窃听、抓包、记录等手段是几乎没有成功的可能。
然而,电话银行却存在着被搭线窃听的严重安全隐患。虽然现在的公共电话网都采用了音频方式,但搭线窃听还原拨号数字却仍然是非常简单的一件事情,而且很难被察觉。先说电话网的布线方式,在小区以及楼宇的走道内都可以接触到电话配线架,只需要打开铁箱子门,使用简单的设备就可以听到别人的语音通话,同时也可以盗用别人的电话号码进行拨打,要得到某条电话线路上的拨号数据需要的也仅仅是时间。普通电话无论语音还是拨号数据从来都不加密,要窃听就是这样简单。再说说电话局端,那里记录了用户的所有电话拨打使用数据,包括所有的电话按键信息,我们也不能排除这些数据被电话局内别有用心的人得到或者泄漏。还要说说企业的PBX程控交换,为了防止员工肆意拨打长途或声讯电话,企业一般都会有程控电话记录和管理设备,内部电话的拨号数据在程控设备的监视软件上是一幕了然,而谁又能保证可以看到这些数据的人不会起邪念呢?
为什么说这些拨号数据如此重要呢?这就得了解一下电话银行的运作模式。先拨入银行电话,然后按照提示输入卡号,然后是密码或者查询密码,授权通过后就可以进行电话银行可提供的业务操作。而这些操作中最要命的往往就是那些直接的资金操作,比如转帐、缴费等。有些考虑稍微周到些的银行在进行这些关键操作时会让用户再次输入交易密码,这个往往就是银行卡在ATM上的取款密码。这些用户键入的数字,一旦被记录,就很容易通过#号,一般银行卡号长度等信息分析出具体卡号和密码,有了这些偷盗者的任务也完成大半了。
为了避免这些显而易见的安全隐患,有些银行把电话银行和网上银行的密码以及ATM取款密码相互独立开来,同时降低电话银行可操作的业务种类和级别,在电话银行中仅使用查询密码等手段减小风险。这些都是积极的尝试和进步,但是有些银行却很不注重这些,有些国内银行做的很差。这些银行在不告知用户的情况下,就默认开通了电话银行业务,而且默认密码就是取款密码。更有甚者要求开通网上银行必须开通电话银行,初时密码是一样的,要修改则是以后的事情。但是对于用户而言,不是每个人都那么注重个人隐私的保护和这些敏感信息的安全性,他们不会懂得为什么要查询密码和交易密码两个密码?用一个不是更好记忆吗?这就需要银行方面更多的提供解释和为用户多考虑,而不是贪图自己的系统设计方便却把用户的安全性丢在一边。
可喜的是,我们看到种种努力和改进都在进行。一些银行的信用卡电话银行已取消了简单的密码输入作为身份审核的一贯方式,二是采用了人工提问的方式来确定电话者的身份。这样一对一的电话银行业务受理方式也是用户喜欢的方式,而不是对着答录机按数字。但是这样的模式,需要更多的电话服务人员,业务的效率不高。最近一种新的电话银行身份鉴别方式在美国进行着试用,就是采用语音识别手段来判断用户身份。这需要对电话线路进行改造和专用的电话设备,用户只需对着答录机的提示说出卡号或者一段句子就可以进入电话银行。这可以说是一个不错的想法和创意,但是也有许多人持怀疑态度。首先是因为语音识别系统的错误率太高,再者很难保证打电话进来的人是不是也用录音来进行欺骗。
不管用什么方法,我们都希望自己存在银行内的钱的安全,自己使用网银或者电话银行业务的安全。虽然目前我们的电话银行系统因为种种原因存在这样那样的安全隐患,但是随着中国电子银行安全管理办法的出台,更多的银行高层开始关注电子银行的安全,因此,电话银行、网上银行的安全性是可以有所期待的。

Cisco MARS发现多处漏洞

上周五还去参加cisco的MARS(Cisco Security Monitoring, Analysis and Response System (CS-MARS))产品培训,今天就报出发现多处漏洞,同时我对此产品也不太看好,一是收购别人的软件、二是cisco做安全还太嫩了。
 
Cisco released earlier today an advisory pointing out vulnerabilities in one of their security managment products: Cisco Security Monitoring, Analysis and Response System (CS-MARS).

  • The included Oracle database has default passwords
  • The included JBoss webserver allows remote code execution
  • A privilege escalation problem that allows administrators to gain root access to the machine

Cisco今天早先时候发布的一份说明指出他们的安全管理产品MARS中发现多处漏洞。

  • MARS搭载的Oracle数据库使用了Oracle的许多默认帐号,同时也使用了默认的密码,这就造成了一旦用户可以访问数据库的时候就可以直接得到敏感数据信息。
  • MARS搭载的JBoss web应用服务器软件,其中含有的一个组件会允许远程访问,这样导致未经授权的用户可以以MARS管理员的权限级别远程执行随意指令。
  • MARS的命令行包含许多漏洞,可以让经过授权的管理员以root权限来执行任意指令。

估计MARS在国内还没卖出去几套,不过也得留心一下咯。及时升级到4.2.1及以后版本,或者访问cisco网站获得当前4.2.0对此漏洞的补丁。

密钥管理是企业安全的核心

长久以来密码学一直被用作保护数据的安全传输,而如今它被更多的用在了保护数据库、文件系统、存储介质中的数据。不仅如此,密码学已经被扩展到用于加强数据的私密性、完整性和唯一性。
  • 公钥体系的大规模的应用,身份证书、个人签名、加密、双向认证等手段来保护网站信息,保护邮件内容和重要文档的安全。
  • 到处都可以见到的SSL技术。不仅仅再局限在电子商务上的应用,SSL更多的被植入企业应用和网络设备中。
  • 即插即用数据层面的保护。要采取数据加密往往意味着改写软件应用、编写客户化的代码、改变业务流程,而如今最新的解决方案可以对数据、文件系统、存储介质进行透明化的加密。
  • 密码学的瓶颈。担心加密会严重影响系统的吞吐率已经没有什么必要了,这都要感谢快速的加解密装置。
除了这些好处,密码技术仍然受到部署和管理上的强烈挑战。不过可以消除这些路障的市场因素讲起到关键作用。
  • 不贵但是可以实现强身份认证的动态令牌。企业都不希望仅仅依赖于简单的口令作为访问保密系统的安全保障,但是要强加这些安全保护,投资非常大。如今,在竞争下的产物--动态令牌,使用USB棒等小设备就完成了复杂的功能,同时大大降低了成本。
  • 可升级的密钥管理。对于密码的生命周期来说,密钥管理变得越来越重要。这同样驱使了升级的需求。许多类似的产品可以实现在大的企业环境中进行密钥的管理和自动分发。
  • 针对设备和人员的身份识别管理系统。早期的身份识别管理系统也负责权限和是否可以进入业务系统的管理,但是渐渐的这些系统也覆盖了对设备和自动系统的身份识别和授权功能,而不仅仅针对人员了。
一切变得非常清楚,企业需要为数据和内容的安全打下坚实的密码学基础,但是建立安全意义上的密钥系统仅仅是个开始。成功取决于部署、管理和贯彻良好密钥管理策略的能力。

针对powerpoint的最新漏洞攻击

被Symantec命名为Trojan.PPDropper.B的木马病毒正利用微软的Powerpoint的漏洞进行传播和攻击。微软方面并没有引起足够的重视,认为传播面不会很广。月初微软例行发布了7月的几个安全更新,其中有office的excel和word的漏洞补丁,但是没有涉及此次发现powerpoint的漏洞。因此大家要提高警惕!
这个木马,利用微软的PPT漏洞,注入系统几个木马病毒文件,用来进行远程控制调用。信件可能是从gmail发送过来的,邮件的主题和附件常见为中文名称,附件为[中文名].ppt,一旦运行该ppt文件,就会执行此恶意代码并释放木马至操作系统目录%System%regvrt.exe( Backdoor.Bifrose.E的一种变种,symantec命名),并在EXPLORER.EXE中插入进程并重新生成一个干净的ppt文档,同时显示ppt内容。
在微软没有发布该漏洞补丁之前,请大家及时升级防毒软件,不要轻易打开来路不明的ppt文档。