2010年最具威胁的25大软件编程漏洞

需积分: 10 106 浏览量更新于2024-07-17 收藏 384KB PDF 举报

2010年的"CWE/SANS Top 25 Most Dangerous Software Errors"是由美国麻省理工学院(MITRE Corporation)和SANS Institute合作编撰的一份权威清单，旨在揭示在软件开发中最常见的、对安全构成严重威胁的25个编程错误。这份报告于2010年6月29日发布，由Bob Martin、Mason Brown、Alan Paller和Dennis Kirby四位项目协调人共同编纂，Steve Christey担任文档编辑。这份排行榜的重要性在于，它强调了这些错误的普遍性和危害性，它们可能导致软件漏洞，使得攻击者能够轻易地控制软件，窃取数据，甚至完全阻止软件运行。编写高质量、安全的软件是所有软件开发者的首要任务，而这份清单提供了一个教育和提升安全意识的工具，帮助程序员识别并避免在软件发布前可能出现的常见错误。通过这份列表，软件消费者可以更明智地选择和评估软件的安全性，确保他们使用的软件能有效抵御潜在威胁。同时，安全研究者也可以将这份清单作为关注的重点，集中精力在所有已知安全弱点中那些具有重要意义的部分，从而推动整个行业的安全改进。每一项错误都根据其风险级别、影响范围以及易于被利用的程度进行了分类，这使得开发者和安全专家能够有针对性地进行代码审查和修复，降低软件安全风险。例如，错误类型可能包括缓冲区溢出（Buffer Overflow）、空指针引用（Null Pointer Dereference）、SQL注入（SQL Injection）等，这些都是历史上导致大规模安全事件的常见问题。阅读和理解这份Top 25清单对于任何与软件开发相关的专业人员来说都是至关重要的，它不仅提供了预防措施，也促进了业界对软件安全的持续关注和提升。随着技术的发展，每年的CWE/SANS报告可能会有所更新，反映出最新的威胁和最佳实践，以适应不断变化的安全环境。因此，持续学习和跟进这些知识对于保持软件安全至关重要。

CWE-79: Improper Neutralization of Input During Web Page

Generation ('Cross-site Scripting')

Summary

Weakness Prevalence High

Consequences Code execution, Security bypass

Remediation Cost Low

Ease of Detection Easy

Attack Frequency Often

Attacker Awareness High

Discussion

Cross-site scripting (XSS) is one of the most prevalent, obstinate, and dangerous

vulnerabilities in web applications. It's pretty much inevitable when you combine the

stateless nature of HTTP, the mixture of data and script in HTML, lots of data

passing between web sites, diverse encoding schemes, and feature-rich web

browsers. If you're not careful, attackers can inject Javascript or other browser-

executable content into a web page that your application generates. Your web page

is then accessed by other users, whose browsers execute that malicious script as if it

came from you (because, after all, it *did* come from you). Suddenly, your web site

is serving code that you didn't write. The attacker can use a variety of techniques to

get the input directly into your server, or use an unwitting victim as the middle man

in a technical version of the "why do you keep hitting yourself?" game.

Technical Details | Code Examples | Detection Methods | References

Prevention and Mitigations

Architecture and Design

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that

make this weakness easier to avoid.

Examples of libraries and frameworks that make it easier to generate properly encoded output include

Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

Implementation, Architecture and Design

Understand the context in which your data will be used and the encoding that will be expected. This is

especially important when transmitting data between different components, or when generating outputs

that can contain multiple encodings at the same time, such as web pages or multi-part mail messages.

Study all expected communication protocols and data representations to determine the required encoding

strategies.

For any data that will be output to another web page, especially any data that was received from external

inputs, use the appropriate encoding on all non-alphanumeric characters.

Parts of the same output document may require different encodings, which will vary depending on whether

the output is in the:

HTML body

Element attributes (such as src="XYZ")

URIs

JavaScript sections

Cascading Style Sheets and style property

etc. Note that HTML Entity Encoding is only appropriate for the HTML body.

Consult the XSS Prevention Cheat Sheet [REF-16] for more details on the types of encoding and escaping

that are needed.

Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on

the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values

after the checks have been performed, or by changing the client to remove the client-side checks entirely.

Then, these modified values would be submitted to the server.

Architecture and Design

If available, use structured mechanisms that automatically enforce the separation between data and code.

These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically,

instead of relying on the developer to provide this capability at every point where output is generated.

Implementation

For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8.

When an encoding is not specified, the web browser may choose a different encoding by guessing which

encoding is actually being used by the web page. This can cause the web browser to treat certain sequences

as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to

encoding/escaping.

Implementation

With Struts, you should write all data from form beans with the bean's filter attribute set to true.

Implementation

To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In

browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox),

this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts

that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers.

More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP

headers, including the Set-Cookie header in which the HttpOnly flag is set.

Effectiveness: Defense in Depth

Implementation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of

acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to

specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or

malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential

attacks or determining which inputs are so malformed that they should be rejected outright.

When performing input validation, consider all potentially relevant properties, including length, type of

input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields,

and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid

because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red"

or "blue."

When dynamically constructing web pages, use stringent whitelists that limit the character set based on the

expected value of the parameter in the request. All input should be validated and cleansed, not just

parameters that the user is supposed to specify, but all data in the request, including hidden fields, cookies,

headers, the URL itself, and so forth. A common mistake that leads to continuing XSS vulnerabilities is to

validate only fields that are expected to be redisplayed by the site. It is common to see data from the

request that is reflected by the application server or the application that the development team did not

anticipate. Also, a field that is not currently reflected may be used by a future developer. Therefore,

validating ALL parts of the HTTP request is recommended.

Note that proper output encoding, escaping, and quoting is the most effective solution for preventing XSS,

although input validation may provide some defense-in-depth. This is because it effectively limits what will

appear in output. Input validation will not always prevent XSS, especially if you are required to support free-

form text fields that could contain arbitrary characters. For example, in a chat application, the heart

emoticon ("<3") would likely pass the validation step, since it is commonly used. However, it cannot be

directly inserted into the web page because it contains the "<" character, which would need to be escaped

or otherwise handled. In this case, stripping the "<" might reduce the risk of XSS, but it would produce

incorrect behavior because the emoticon would not be recorded. This might seem to be a minor

inconvenience, but it would be more important in a mathematical forum that wants to represent

inequalities.

Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate

encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input

validation is still a useful technique, since it may significantly reduce your attack surface, allow you to

detect some attacks, and provide other security benefits that proper encoding does not address.

CWE-89: Improper Neutralization of Special Elements used in

an SQL Command ('SQL Injection')

Summary

Weakness Prevalence High

Consequences Data loss, Security bypass

Remediation Cost Low

Ease of Detection Easy

Attack Frequency Often

Attacker Awareness High

Discussion

These days, it seems as if software is all about the data: getting it into the database,

pulling it from the database, massaging it into information, and sending it elsewhere

for fun and profit. If attackers can influence the SQL that you use to communicate

with your database, then suddenly all your fun and profit belongs to them. If you

use SQL queries in security controls such as authentication, attackers could alter the

logic of those queries to bypass security. They could modify the queries to steal,

corrupt, or otherwise change your underlying data. They'll even steal data one byte

at a time if they have to, and they have the patience and know-how to do so.

Technical Details | Code Examples | Detection Methods | References

Prevention and Mitigations

Architecture and Design

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that

make this weakness easier to avoid.

For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can

provide significant protection against SQL injection if used properly.

Architecture and Design

If available, use structured mechanisms that automatically enforce the separation between data and code.

These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically,

instead of relying on the developer to provide this capability at every point where output is generated.

Process SQL queries using prepared statements, parameterized queries, or stored procedures. These

features should accept parameters or variables and support strong typing. Do not dynamically construct and

execute query strings within these features using "exec" or similar functionality, since you may re-introduce

the possibility of SQL injection.

Architecture and Design, Operation

Run your code using the lowest privileges that are required to accomplish the necessary tasks. If possible,

create isolated accounts with limited privileges that are only used for a single task. That way, a successful

attack will not immediately give the attacker access to the rest of the software or its environment. For

example, database applications rarely need to run as the database administrator, especially in day-to-day

operations.

Specifically, follow the principle of least privilege when creating user accounts to a SQL database. The

database users should only have the minimum privileges necessary to use their account. If the

requirements of the system indicate that a user can read and modify their own data, then limit their

privileges so they cannot read/write others' data. Use the strictest permissions possible on all database

objects, such as execute-only for stored procedures.

剩余75页未读，继续阅读

粉丝:
资源:

2010年最具威胁的25大软件编程漏洞

恶意弹出1000个cmd命令窗口

2010最严重安全漏洞

CWE与SANS共同评定的25个最危险编程错误

2010年最危险的25种编程错误

浅析PHP编程中10个最常见的错误

EGCode:危险地松散键入（未发布的同类）的编程语言的概念的错误实现

C++语言99个常见编程错误.pdf

c语言出错中英文对照表 关于c编程编译错误的

C++编程：编译器无法捕捉的8种危险错误

三菱PLC编程错误调试与安全指南

最新资源

c语言出错中英文对照表关于c编程编译错误的