互联网安全攻击及防范手册

上传人:shaoy****1971 文档编号:108131733 上传时间:2019-10-22 格式:DOC 页数:38 大小:636.50KB
返回 下载 相关 举报
互联网安全攻击及防范手册_第1页
第1页 / 共38页
互联网安全攻击及防范手册_第2页
第2页 / 共38页
互联网安全攻击及防范手册_第3页
第3页 / 共38页
互联网安全攻击及防范手册_第4页
第4页 / 共38页
互联网安全攻击及防范手册_第5页
第5页 / 共38页
点击查看更多>>
资源描述

《互联网安全攻击及防范手册》由会员分享,可在线阅读,更多相关《互联网安全攻击及防范手册(38页珍藏版)》请在金锄头文库上搜索。

1、安全攻击及防范手册_版本 1.0 2010年8月1 概述1.1 简介 当今世界,Internet(因特网)已经成为一个非常重要的基础平台,很多企业都将应用架设在该平台上,为客户提供更为方便、快捷的服务支持。这些应用在功能和性能上,都在不断的完善和提高,然而在非常重要的安全性上,却没有得到足够的重视。随着WEB技术应用的范围越来越广泛,WEB技术相关的安全漏洞越来越多的被挖掘出来,而针对WEB站点的攻击已经成为了最流行的攻击途径。 不久前项目管理部对公司内外重点系统进行了一次安全隐患分析测试,并总结出了公司安全测试问题分类及描述的报告文档。本文针对此报告中提到的一些重大安全隐患问题逐一分析,并给

2、出相应的解决方案。1.2 参考资料Java安全性编程实例网站系统安全开发手册企业级Java安全性(构建安全的J2EE应用)2 WEB安全隐患及预防措施2.1 会话标识未更新2.1.1 描述登陆过程前后会话标识的比较,显示它们并未更新,这表示有可能伪装用户。初步得知会话标识值后,远程攻击者有可能得以充当已登录的合法用户。2.1.2 安全级别高。2.1.3 安全风险可能会窃取或操纵客户会话和 cookie,它们可能用于模仿合法用户,从而使黑客能够以该用户身份查看或变更用户记录以及执行事务。2.1.4 解决方案u 不要接受外部创建的会话标识。u 始终生成新的会话,供用户成功认证时登录。u 防止用户操

3、纵会话标识。u 请勿接受用户浏览器登录时所提供的会话标识。u 如果有验证码的。验证码改用application存储。同时记得释放资源2.1.5 技术实现u 登陆界面和登陆成功的界面一致时修改后台逻辑,在验证登陆逻辑的时候,先强制让当前session过期,然后用新的session存储信息。u 登陆界面和登陆成功的界面不一致时在登陆界面后增加下面一段代码,强制让系统session过期。request.getSession().invalidate();/清空sessionCookie cookie = request.getCookies()0;/获取cookiecookie.setMaxAge(

4、0);/让cookie过期 注意:框架2.0已经修改了登陆验证类,登陆成功后会清理掉当前session,重新创建一个新的session。凡是使用框架2.0的项目均可统一增加此功能。2.2 不充分帐户封锁2.2.1 描述程序没有使用锁定功能,可以穷举密码,可以造成蛮力攻击,恶意用户发送大量可能的密码和/或用户名以访问应用程序的尝试。 由于该技术包含大量登录尝试,未限制允许的错误登录请求次数的应用程序很容易遭到这类攻击。2.2.2 安全级别高。2.2.3 安全风险可能会升级用户特权并通过 Web 应用程序获取管理许可权。2.2.4 解决方案请确定允许的登录尝试次数(通常是 3-5 次),确保超出允

5、许的尝试次数之后,便锁定帐户。 为了避免真正的用户因帐户被锁定而致电支持人员的麻烦,可以仅临时性暂挂帐户活动,并在特定时间段之后启用帐户。帐户锁定大约 10 分钟,通常用这样的方法阻止蛮力攻击。2.2.5 技术实现u 提供锁定信息配置类,可根据项目特定需求修改此配置信息。u 修改登陆验证逻辑,根据上面的配置信息提供帐户锁定功能。注意: 框架2.0已经实现了此功能,凡是使用框架2.0的项目均可统一增加此功能。2.3 可预测的登录凭证2.3.1 描述发现应用程序会使用可预期的认证凭证(例如:admin+admin、guest+guest)。 攻击者很容易预测用户名和密码,登录应用程序,从而获取未获

6、授权的特权。2.3.2 安全级别高。2.3.3 安全风险可能会升级用户特权并通过 Web 应用程序获取管理许可权。2.3.4 解决方案不应使用易于预测的凭证(例如:admin+admin、guest+guest、test+test 等),因为它们可能很容易预测,可让用户不当进入应用程序。2.3.5 技术实现只要养成良好的习惯,坚决不使用容易预测的名和密码,即可彻底杜绝此类问题。2.4 登录错误消息凭证枚举2.4.1 描述当试图利用不正确的凭证来登录时,当用户输入无效的用户名和无效的密码时,应用程序会分别生成不同的错误消息。 通过利用该行为,攻击者可以通过反复试验(蛮力攻击技术)来发现应用程序的

7、有效用户名,再继续尝试发现相关联的密码。2.4.2 安全级别高。2.4.3 安全风险可能会升级用户特权并通过 Web 应用程序获取管理许可权。2.4.4 解决方案不论名和密码哪个错误,都提示同样的消息。且同时加上登陆失败次数达到规定的帐户锁定功能。2.4.5 技术实现不论名和密码哪个错误,都提示如下所示同样的消息:一旦某个帐户连续登陆失败次数达到了规定的数值,就会按配置的时间被锁定,如下提示:如此一来,攻击者就没机会穷举帐户和密码了,此类攻击也就不可能发生了! 注意:框架2.0已经实现了此功能,凡是使用框架2.0的项目均可统一增加此功能。2.5 已解密的登录请求2.5.1 描述通过HTTP P

8、OST 发送表单数据,这些数据将在HTTP报文中以明文的形式传输。对于一些敏感的数据(如用户名/密码、信用卡密码)以传统的HTTP报文传输存在巨大的风险。2.5.2 安全级别中。2.5.3 安全风险可能会窃取诸如用户名和密码等未经加密即发送了的用户登录信息。2.5.4 解决方案(1) 饶过AppScan软件扫描(2) 对提交的敏感信息,一律以加密方式传给服务器。(3) 采用基于SSL的HTTPS传输协议,对提交的敏感信息在传输过程中加密。 敏感信息包括:用户名、密码、社会保险号码、信用卡号码、驾照号码、电子邮件地址、电话号码、邮政编码等。注意:如果不是基于SSL的HTTPS传输协议的话。对于提

9、交的敏感信息即使加密后,AppScan软件同样认为该漏洞存在。所以避免这一漏洞的有效方案是饶过扫描或者采用基于SSL的HTTPS传输协议。虽然采取HTTPS传输数据有很高的安全性,但是也有以下几个显著的缺点:u 需要申请一个合法组织颁发的用来加/解密的证书。u 部署、配置繁琐。u 同样的硬件环境,效率比HTTP慢很多。 通过上述分析,采取基于SSL的HTTPS传输协议,付出的代价有点大,是否有必要这样做,值得深入讨论。:把text=password这个用其他的代替,就可以解决已解密的登录请求密  码: js代码function hiddenPass(e) e = e ? e : window.event; var kcode = e.which ? e.which : e.keyCode; var pass = document.getElementById(password1); var j_pass = document.getElementById(password); if(kcode!=8) var keych

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 办公文档 > 其它办公文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号