OWASP前十大漏洞

合集下载

OWASP TOP 10

OWASP TOP 10

OWASP TOP 10 20201)注入2)失效身份认证和会话管理3)敏感信息泄露4)XML外部实体注入攻击(XXE)5)访问控制中断6)安全性错误配置7)跨站脚本攻击(XSS)8)不安全的反序列化9)使用具有已知漏洞的组件10)日志记录和监控不足注入当攻击者将无效的数据发送给web应用程序来让其执行为设计的操作,就会发生代码注入问题。

此安全漏洞最常见的示例便是使用不受信任数据的SQL查询,代码注入漏洞的核心是缺乏对web应用程序使用的数据的验证和清理。

任何接收参数作为输入的内容都可能受到代码注入攻击。

危害:注入可以使数据丢失或者被破坏掉,并且缺乏可审计性或者拒绝服务。

注入漏洞有时甚至可导致完全接管主机。

防御方法:1)首选方法是使用安全的API接口,该API避免完全使用解释器,或者说提供参数化的接口或迁移为使用对象关系映射工具(ORM)。

注意:即使说你参数化了,但是如果PL/SQL或者T-SQL连接查询和数据,或者说使用EXCLUTE IMMEDIATE 或者exec()执行恶意数据,则存储过程仍然可以引入SQL注入。

2)使用肯定或“白名单”服务器端输入验证,由于许多应用程序都需要特殊字符,例如文本区域或者移动应用程序的API,因此这并不是一个完整的防御措施3)对于任何残留的动态查询,请使用该解释程序的特定转义语义来转义特殊字符,注意,表名(table),列名(column)等SQL结构无法转义,因此用户提供的结构名很危险,这是报表编写软件中的常见问题4)在查询中使用limit和其他SQL控件可防止SQL注入的情况下大量泄露记录总结:数据和web引用程序逻辑要分离实施限制,以在成功进行注入攻击的情况下限制数据公开失效的身份验证和会话管理身份验证漏洞可能让攻击者能尝试控制他们在系统中想要的任何账户,甚至更遭的是,获得对系统的完全控制,身份验证和会话管理失效通常是指在应用程序身份验证机制上发生的逻辑问题,例如恶意行为者脑力破解系统中的有效用户。

OWASP_移动应用安全10大问题

OWASP_移动应用安全10大问题

(BETA)鸣谢感谢SecZone自2014年Mobile TOP 10项目成立以来,对该项目持续的跟进、翻译、研究、分享。

同时,我们也对该项目的主要翻译人员王颉表示感谢。

Mobile TOP 10 项目支持单位:目录鸣谢 (2)OWASP Mobile Top 10简介 (5)M1:平台使用不当 (7)1.1.概述 (7)1.2.明显特征 (7)1.3.风险 (8)1.4.举例 (8)M2:不安全的数据存储 (9)2.1.概述 (9)2.2.明显特征 (10)2.3.风险 (10)2.4.举例 (空) (10)M3:不安全的通信 (11)3.1.概述 (11)3.2.明显特征 (11)3.3.风险 (11)3.4.举例 (12)M4:不安全的身份验证 (13)4.1.概述 (13)4.2.明显特征 (13)4.3.风险 (14)4.4.举例 (14)M5:加密不足 (16)5.1.概述 (16)5.2.明显特征 (16)5.3.风险 (16)5.4.举例 (17)M6:不安全的授权 (18)6.1.概述 (18)6.2.明显特征 (18)6.3.风险 (18)6.4.举例 (18)M7:客户端代码质量问题 (19)7.1.概述 (19)7.2.明显特征 (19)7.3.风险 (19)7.4.举例 (19)M8:代码篡改 (20)8.1.概述 (20)8.2.明显特征 (20)8.3.风险 (20)8.4.举例 (20)M9:逆向工程 (21)9.1.概述 (21)9.2.明显特征 (21)9.3.风险 (21)9.4.举例 (21)M10:无关的功能 (22)10.1.概述 (22)10.2.明显特征 (22)10.3.风险 (22)10.4.举例 (22)OWASP Mobile Top 10简介M1-平台使用不当这个类别包括平台功能的滥用,或未能使用平台的安全控制。

它可能包括Android 的意图(intent)、平台权限、TouchID的误用、密钥链(KeyChain)、或是移动操作系统中的其他一些安全控制。

WEB安全性-2010_OWASP_TOP10

WEB安全性-2010_OWASP_TOP10

OWASP TOP 10-2010开放式Web应用程序安全项目(OWASP,Open Web Application Security Project)是一个组织,它提供有关计算机和互联网应用程序的公正、实际、有成本效益的信息。

其目的是协助个人、企业和机构来发现和使用可信赖软件。

OWASP发布了最新的Web应用脆弱性的top 10,这是继2007年OWASP对TOP10进行修订后进行的又一次更改,该版本暂定为OWASP TOP 10- 2010。

在新版本的OWASP TOP10中主要由以下变化:1. Top10的命名发生了变化。

原先的Top10全称为“The top 10 most critical web application security vulnerabilities”,即“Web应用的十大关键脆弱性”,现在Top10的全称为“The top 10 most critical web application security risks”,即“Web应用的十大关键风险”2. OWASP Top 10的风险评估方法此次Top 10的评估是依据OWASP的风险评估方法来对OWASP TOP10排序的。

3. 替换了2个风险此次Top 10与2007年的Top 10相比,在内容上去掉了“Malicious File Execution”(恶意文件执行)和“Information leakage and improper error handling”(信息泄露及不恰当的错误处理),增加了“Security misconfiguration”(错误安全配置)和“Unv alidated redirects and forwards”(未验证的重定向和传递)。

OWASP TOP10 2007 OWASP TOP10 2010A2-注入 A1-注入A1-跨站脚本(XSS) A2-跨站脚本(XSS)A7-错误的认证和会话管理 A3-错误的认证和会话管理A4-不正确的直接对象引用 A4-不正确的直接对象引用A5-伪造跨站请求(CSRF) A5-伪造跨站请求(CSRF)A6-安全性误配置A10-限制远程访问失败 A7-限制远程访问失败A8-未验证的重定向和传递A8-不安全的加密存储 A9-不安全的加密存储A9-不足的传输层保护 A10-不足的传输层保护A3-恶意文件执行A6-不安全的通讯OWASP风险评估方法OW ASP所选取的10大风险是依据OW ASP的风险评估方法,我们从标准的风险模型开始,即风险=可能性*后果,下面我们以以下步骤来说明某个风险的严重程度:第一步:识别风险识别风险作为评估的第一步,我们必须找到与这个风险相关的威胁、相应的攻击方法、隐含在里面的脆弱性以及最终可能造成的后果,当然可能存在多种攻击方法和多种后果,在评估时我们往往会采用最坏选择,这样就能更客观的反应该风险的最终评级;第二步:考虑影响可能性的因素通常,我们不可能很精准的说出某个风险的可能性数值,所以我们一般用高、中、低来表示,而且影响某个风险的可能性的因素有很多,对于每个因素我们用0到9的数值来表示。

OWASPTOP10

OWASPTOP10

OWASPTOP10学习备份TOP1-注⼊简单来说,注⼊往往是应⽤程序缺少对输⼊进⾏安全型检查所引起的,攻击者把⼀些包含指令的数据发送给解释器,解释器会把收到的数据转换成指令执⾏。

常见的注⼊包括sql注⼊,--os-shell,LDAP(轻量),xpath(XPath即为XML路径语⾔,它是⼀种⽤来确定(的⼦集)⽂档中某部分位置的语⾔),HQL注⼊等。

危害如下:注⼊可以导致数据丢失或被破坏,缺乏可审计性或拒绝服务。

注⼊漏洞有时甚⾄可导致完全接管主机如何防范:1.使⽤安全的API,避免使⽤解释器2.对输⼊的特殊的字符进⾏ESCAPE转义处理例⼦:LIKE '%M%' ESCAPE ‘M’使⽤ESCAPE关键字定义了转义字符“M”,告诉DBMS将搜索字符串“%M%”中的第⼆个百分符(%)作为实际值,⽽不是通配符3.使⽤⽩名单来规范化的输⼊验证⽅法TOP2-失效的⾝份认证和会话管理与认证和会话管理相关的应⽤程序功能往往得不到正确实施,导致了攻击者可以破坏密码,密钥,会话令牌或实施漏洞冒充其他⽤户⾝份危害如下:这些漏洞可能导致部分甚⾄全部账户遭受攻击,⼀旦攻击成功,攻击者就能执⾏合法的任何操作如何防范:1.使⽤内置的会话管理功能2.通过认证的问候3.使⽤单⼀的⼊⼝点4.确保在⼀开始登录SSL保护的⽹页TOP3-跨站XSS跨站脚本是最普遍的web应⽤安全漏洞。

当应⽤程序在发送给浏览器的页⾯中包含⽤户提供的数据,但没有经过适当验证和转义,就会导致跨站危害如下:攻击者在受害者浏览器中执⾏脚本以劫持⽤户会话,插⼊恶意内容,重定向⽤户,使⽤恶意软件劫持⽤户浏览器等种类:存储型,反射型,DOM型如何防范:1.验证输⼊2.编码输出(⽤来确保输⼊的字符被视为数据,⽽不是作为html被浏览器所解析)TOP4-不安全的对象直接引⽤意指⼀个已经授权的⽤户通过更改访问时的⼀个参数,从⽽访问到原本其并没有得到授权的对象危害如下:这种漏洞可以损坏参数所引⽤的所有数据如何防范:1.使⽤基于⽤户或会话的间接对象访问,这样可防⽌攻击者直接攻击为授权资源2.访问检查:对任何来⾃不受信源所使⽤的所有对象进⾏访问控制检查3.避免在url或⽹页中直接引⽤内部⽂件名或数据库关键字4.验证⽤户输⼊和url请求,拒绝包含./ ../的请求TOP5-伪造跨站请求(CSRF)跨站请求伪造,利⽤了⽹站允许攻击者预测特定操作所有细节这⼀特点。

OWASP 十大移动安全风险-Android 中文版

OWASP 十大移动安全风险-Android 中文版

owasp-mobile2016-M3
不安全的通信
这涵盖不良握手、不正确的 SSL 版本、弱协商、敏感资产 的明文通信等。
owasp-mobile2016-M3
不安全的通信
这涵盖不良握手、不正确的 SSL 版本、弱协商、敏感资产 的明文通信等。
该类别捕获验证最终用户或不
良会话管理的意图。这包括在
owasp-mobile- 不安全的身份 必须验证用户身份时未能确定
标准
名称
说明
该类别涵盖滥用平台功能或未
使用平台安全控制。这可能包
owasp-mobile2016-M1

不当使用平台
括 Android 意图、平台权限、 滥用 TouchID、Keychain 或其他 某些属于移动操作系统一部分
的安全控制。有几种方式会使
移动应用程序面临这种风险。
这涵盖不安全的数据存储和意
2016-M4
验证
用户身份,在必要时未能维护
用户身份,以及会话管理缺陷

owasp-mobile2016-M5
不充分加密
该代码对敏感信息资产加密。 但是,此加密从某种程度上来 说并不充分。请注意,任何与 TLS 或 SSL 相关的问题都归入 M3。此外,如果应用程序在应 该加密时完全不使用加密,那 么它可能属于 M2。该类别是 指尝试加密但未正确加密的问 题。
外的数据泄露。当开发团队认
为用户或恶意软件没有权限访
问移动设备的文件系统以及设
owasp-mobile2016-M2
不安全的数据 存储
备数据存储库中的后续敏感信 息时,会出现不安全的数据存 储漏洞。意外的数据泄露(以
前称为侧信道数据泄露)包括

web漏洞评定标准

web漏洞评定标准

Web漏洞评定标准引言随着网络技术的迅速发展,Web应用程序已经成为了人们生活中不可或缺的一部分。

然而,Web应用程序的安全性问题也随之而来,容易受到各种攻击,例如SQL注入、跨站脚本攻击(XSS)、跨站请求伪造(CSRF)等。

为了确保Web应用程序的安全性,我们需要进行漏洞评定,以及采取相应的防护措施。

漏洞评定标准Web漏洞评定标准是一组规则和方法,用于确定Web应用程序中存在的漏洞类型和严重程度。

以下是常见的Web漏洞评定标准:OWASP Top 10OWASP(Open Web Application Security Project)是一个致力于改善Web应用程序安全性的国际组织。

OWASP Top 10是最为经典的Web漏洞评定标准之一,它列举了当前最常见的十种Web漏洞,并按照严重程度排序。

包括以下漏洞类型:- 注入攻击(Injection) - 跨站脚本攻击(XSS) - 不安全的直接对象引用(Insecure Direct Object References) - 跨站请求伪造(CSRF) - 不正确的身份认证与会话管理(Broken Authentication and Session Management) - 剥离攻击(Security Misconfiguration) - 敏感信息泄露(Sensitive Data Exposure) - 无效的重定向与转发(Unvalidated Redirects and Forwards) - 高危组件使用(Using Components with Known Vulnerabilities) - 不充分的日志记录与监控(Insufficient Logging and Monitoring)Common Weakness Enumeration (CWE)CWE是一种用于详细描述软件安全问题的标准化列表,其中包括多种Web漏洞类型。

owasp2021top10漏洞简介

owasp2021top10漏洞简介

owasp2021top10漏洞简介官⽅:接下来简单对各个漏洞再做个描述top1:权限控制失效(Broken Access Control)⽂件包含/⽬录遍历权限绕过(⽔平越权)权限提升(垂直越权)不安全直接对象的引⽤top2:加密失败(Cryptographic Failure)敏感数据传输(通过HTTP、FTP、SMTP等)或以明⽂形式存储(在数据库、⽂件等中)。

使⽤旧的或较弱的加密算法使⽤弱加密密钥或默认加密密钥,或重复使⽤受损密钥与服务器通信时未强制加密或未验证服务器证书。

top3:注⼊(injection)SQL/NoSQL注⼊命令注⼊服务器端模板注⼊头部注射内容注⼊(XSS、HTML注⼊、CSS注⼊)top4:不安全设计( Insecure Design)缺少⽤户输⼊边界可能会导致缓冲区溢出等问题使⽤不安全的API或函数可能会导致妥协:例如,考虑使⽤没有任何种⼦的随机数,或者在不考虑嵌⼊⽂件可能具有的绝对或相对路径的情况下提取归档⽂件。

使⽤⽐所需权限更⾼权限的应⽤程序。

top5:安全配置错误(Security Misconfiguration)在新的OWASP前⼗名列表中,XXE和安全错误配置(2017年的列表)被合并为安全错误配置。

过度许可的特权被分配给实体启⽤了不必要的功能或服务默认帐户保持激活状态,但是默认密码不变安全标头未发送或权限过⼤(例如,权限过⼤的CORS或CSP策略)未启⽤安全功能(防⽕墙规则、SELinux、Windows Defender等)top6:Vulnerable and Outdated Components客户端和服务器端代码中的易受攻击组件(操作系统或软件包、应⽤程序、运⾏时环境)。

不安全的软件配置正在使⽤的组件的依赖关系链中的旧的/未修补的依赖关系。

top7:识别和⾝份验证失败 Identification and Authentication Failures⽆法防⽌⾃动攻击,如凭证内容或暴⼒破解密码密码重置或恢复流程中存在缺陷在电⼦邮件/密码更新、注销、不活动、重新登录后不处理(使其失效或循环)会话标识符top8:软件和数据完整性故障(Software and Data Integrity Failures)维护始终确保您使⽤的应⽤程序是可信的,并且使⽤了合理的安全措施作为⼀名开发⼈员,请确保应⽤程序已签名,并且受信任的数据源也是防篡改的确保您的CI/CD管道是安全的,并且没有任何恶意代码进⼊在代码进⼊⽣产之前对其进⾏审核经常使⽤你的软件,以确保⾼安全级别top9:安全⽇志记录和监控故障(Security Logging and Monitoring Failures)登录和失败的尝试未被记录如果本地保存⽇志的应⽤程序服务器出现故障,则未备份⽇志不提供任何有价值的信息或见解的模糊或不正确的⽇志监控系统⽆法检测可疑活动或⽆法(近)实时发出警报缺少监控和警报系统⽇志不受完整性保护top10:服务器端请求伪造(Server-Side Request Forgery)也就是ssrf向提供的webhook URL发送GET/POST请求的应⽤程序显⽰URL预览的应⽤程序。

OWASP Top 10 安全漏洞列表指南说明书

OWASP Top 10 安全漏洞列表指南说明书

Who Needs OWASP? Create Your Own Top 10 ListIntroductionWhy is your vulnerability list so important?Follow these 4 steps to achieve your custom, comprehensive Top N list Step 1: Gather vulnerability dataStep 2: Normalize the vulnerability dataStep 3: Create a vulnerability frequency tableStep 4: Consider additional risk factorsMoving forward Page 3 Page 3 Page 3 Page 3 Page 4 Page 4 Page 4 Page 5IntroductionA list of critical web application security vulnerabilities is a necessary risk management tool.1 Equally true is that each organization has a different set of vulnerabilities plaguing their applications. To complete a trifectaof fundamental truths, crowdsourced lists such as the OWASP Top 10 rarely reflect an individual organization’s priorities. Given all that, many organizations continue to download the OWASP Top 10 and try to use it to guide their software security efforts. Since this likely won’t achieve the desired result, why not use it as inspiration to create your own evidence-based, customized list?This document guides you through the process of cataloging your firm’s most common web application security vulnerabilities. But, before identifying those vulnerabilities, we must answer one very important question. Why is your vulnerability list so important?Identifying the vulnerabilities most prevalent in your organization’s applications provides real data. Data that encourages your development and security teams to actively improve their skills and processes. However, creating a satisfactory Top N list requires more than simply sorting one day’s or one application’s bug data. Building a list from the results of code review, various security testing methods, and actual incidents experienced by your firm and/or industry allow you to craft a holistic vulnerability list. You’ll then be better prepared to drive change that reduces risk in your organization.Customize your own comprehensive Top N list in 4 stepsStep 1: Gather vulnerability dataTo understand what you’re up against, you’ll first need to gather web application vulnerability data for a given period. Go back as far as you can with the technologies you have. Six months of data should be a minimum benchmark. Obtaining such data is easier to gather if your firm tracks security bugs in a central repository.If no repository currently exists, identify sources that contain vulnerability data. Collect reports associated with these sources. Next, extract the vulnerabilities into a spreadsheet or another data store.1 By “critical” we mean “most undesirable.” By “vulnerabilities” we mean “vulnerability types,” not individual security defects.Step 2: Normalize the vulnerability dataNormalizing vulnerability data ensures that each vulnerability instance is only counted once per application. You don’t want one bug-filled application to skew your results. A step-by-step approach to achieve this involves the following steps:1. Remove all re-test data from the data set. If the first test identifies a vulnerability that is not fixed bythe time a re-test takes place, list the vulnerability only once.2. Correlate penetration testing, incident response, and code review findings to remove multiplevulnerability instances. The instances may have been identified using different methodologies even though the same bug caused them. For instance, a cross-site scripting (XSS) vulnerability could be discovered during source code review, exploited during penetration testing, and abused by a realattacker. You should still list this vulnerability only once.3. Normalize finding names. For instance, the findings identified as “Stored XSS on admin page”and “Stored XSS on help page” could be renamed to read “Stored XSS.” The granularity of nameidentification determines the results of your Top N list. Use your judgement to determine what works best for your organization.Combining and harmonizing results from many kinds of defect discovery methods results in a richer assessment data set. Thus, more accurately reflecting what might be present in production environments.Step 3: Create a vulnerability frequency tableUsing the normalized vulnerability data, create a frequency table to list the number of times a given vulnerability was identified. For example, unsafe use of user-supplied data was identified 100 times throughout 150 applications over the past six months. This frequency table can help predict the likelihood that similar applications have the same vulnerability.Again, simply sorting a day’s bug data by number of occurrences doesn’t produce a satisfactory Top N list. Data changes often due to different testers, tools, processes, and applications. A historical view is important. Even when you have good frequency data, the point is to enable good risk management decisions. That requires additional knowledge.Step 4: Consider additional risk factorsOnce you have vulnerability frequency data, add analysis for three important risk factors:1. Detectability. The likelihood an attacker can discover the vulnerability.2. Exploitability. The likelihood an attacker can exploit that vulnerability.3. Impact. The combined technical and business impact if the vulnerability is successfully exploited.For each vulnerability in your list, add a score for each risk factor on a scale from 1-3 (with 3 being the higher end of the scale).Determining values for these factors are often based on the discovery method of the vulnerabilities. For instance, a vulnerability exploited in the wild (e.g., originating from the incident response report) might merit a higher exploitability than a vulnerability discovered during code review. Likewise, a vulnerability detected during a penetration test likely merits a higher detectability than a vulnerability detected during code review. Don’t hesitate to make adjustments based on professional opinion. Network location (e.g., Internet-facing versus internal), architecture (e.g., mobile versus thick-client), and other such criteria may be useful when assigning risk factor values.Based on the scores from this exercise, you can prepare your Top N list. This list is now customized to fit your organization and its software portfolio. This is one of the most valuable tools your firm can have for software security risk management.Moving forwardYour organization’s software security group (SSG) should periodically update the list and publish a Most Wanted Report. This calls attention to the most vulnerable areas of your firm’s software and applications. Incorporate this list into internal training material.When shown organization-specific vulnerability data, developers are more likely to understand how the material is relevant to their work. They are also better prepared to know when and how to apply what they’ve learned from training.Your Top N list may also open the door to executive attention regarding your firm’s vulnerabilities. These questions will help your teams obtain the resources they need to close gaps and mature the existing software security strategy.Be sure to adapt your approach at regular intervals to keep your Top N list up-to-date. Don’t simply base your security program on a static list. Sample your own data and turn the results into a powerful risk management tool.Synopsys helps development teams build secure, high-quality software, minimizing risks while maximizing speed and productivity. Synopsys, a recognized leader in application security, provides static analysis, software composition analysis, and dynamic analysis solutions that enable teams to quickly find and fix vulnerabilities and defects in proprietary code, open source components, and application behavior. With a combination of industry-leading tools, services, and expertise, only Synopsys helps organizations optimize security and quality in DevSecOps and throughout the software development life cycle.For more information, go to /software.Synopsys, Inc.185 Berry Street, Suite 6500San Francisco, CA 94107 USAContact us:U.S. Sales: 800.873.8193International Sales: +1 415.321.5237Email: *********************。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

OWASP前十大漏洞
十大漏洞原因危害攻击方法
1 跨站脚本
(XSS,Cross Site
Scripting)
CGI程序没有对用
户提交的变量中的
HTML代码进行过
滤或转换;对提交的
数据没有经过适当
的验证或转译
黑客可以利用浏览器
中的恶意脚本获得用
户的数据,破坏网站,
插入有害内容,以及展
开钓鱼式攻击和恶意
攻击。

攻击者注入非法的标
签与脚本最终都要在
客户端执行,攻击的过
程实际上都在客户端
的浏览器上发生的。

能在客户端进行跨站
的不仅仅是HTML标签
与JavaScript脚本,
还包含一些其它的客
户端应用,比如Flash
里的ActionScript脚
本也能辅助发起XSS
攻击
2 注入漏洞(Injection
Flaw)
字符过滤不严紧所
造成的
攻击者可利用注入漏
洞诱使Web应用执行
未预见的命令或数据
库查询,从而对数据库
信息进行窃取、篡改、
删除等
攻击者把一些包含指
令的数据发送给解释
器,解释器会把收到的
数据转换成指令执行。

3 恶意脚本执行
(Malicious File
Excution)
Web应用程序引入
来自外部的恶意文
件并执行文件内容
攻击者可利用恶意文
件执行漏洞进行攻击
取得Web服务器控制
权,进行不法利益或获
取经济利益
攻击者在具有引入功
能程序的参数中修改
参数内容,Web服务器
便会引入恶意程序内
容从而受到恶意文件
执行漏洞攻击
4 不安全的直接对象
参照物(Insecure
Direct Object
Reference)
当网站地址或者其
他参数包含了文件、
目录、数据库记录或
者关键字等参照物
对象时就可能发生
这种攻击
可能在网络接口中暴
露出用户的账号或是
重要文件
攻击者可以通过猜想
或者搜索另一个有效
关键字的方式攻击这
些参数
5 跨站指令伪造
(CSRF,Cross-Site
Request Forgery)
它们是根据会话
cookie或者“自动记
忆”功能来授权指令

攻击者能让受害用户
修改的任何数据,或者
是执行允许使用的任
何功能
已登入Web应用程序
的合法使用者执行到
恶意的HTTP指令,但
Web应用程序却当成
合法需求处理,使得恶
意指令被正常执行
6 信息泄露和错误处
理不当(Information
Leakage and
Improper Error
Handing)
有些系统没有统一
的异常处理页面,用
户访问出现错误时
会展现给用户调试
错误,甚至SQL脚
本错误
可能将用户的隐私信
息、软件的配置或者其
他内部资料泄露出去
WEb应用程序的执行
错误信息包含敏感资
料,黑客利用这些信息
可以知道一些重要资

7 不安全的认证和会
话管理(Broken
Authentication and
Session
Management)
Web应用程序中自
行撰写的身份验证
相关功能有缺陷
可能导致部分甚至全
部账户遭受攻击。

一旦
攻击成功,攻击者能执
行合法用户的任何操
作。

因此特权账户会造
成更大的破坏
攻击者破坏密码、密
钥、会话令牌或利用实
施漏洞冒充其他用户
身份
8 不安全的加密存储
设备(Insecure
Cryptographic
Storage)
Web应用程序员没
有对敏感资料使用
加密、使用较弱的加
密演算法或将密钥
储存于容易被取得
之处
攻击者能够取得或是
篡改机密的或是私有
的信息;通过这些秘密
的窃取从而进行进一
步的攻击;造成企业形
象破损,用户满意度下
降,甚至会有法律诉讼

由于没有对重要文件
加密或是很好加密的
话,黑客就利用抓包工
具获得重要文件,便可
直接或是简单的解密
就可查看文件
9 不安全的通信
(Insecure
Communucation)
传输敏感性资料时
并未使用HTTPS或
其他加密方式
攻击者能够取得或是
篡改机密的或是私有
的信息;通过这些秘密
的窃取从而进行进一
步的攻击;造成企业形
象破损,用户满意度下
降,甚至会有法律诉讼

攻击者通过一些黑客
工具截取数据包,从而
获得用户信息
10 未对网站地址的访
问进行限制(Failure
to Restrict URL
Access)
某些网页因没权限
控制,使得攻击者可
透过网址直接存取;
对未授权的网页内容
做修改、删除等操作
攻击者能够很容易的
伪造请求直接访问未
被授权的页面
主要参考:
1. /p-274952440.html
2.
https:///index.php/Taiwan#.E5.8D.81.E5.A4.A7Web.E8.B3.87.E5.AE.89.E6.BC.8
F.E6.B4.9E.E5.88.97.E8.A1.A8
3. /s/blog_5610604c0100p36q.html
SKYJIL YGAO
2012.07.02。

相关文档
最新文档