Shulou(Shulou.com)06/03 Report--

Editor to share with you the example analysis of XML injection, I believe that most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

0x01 introduction

Some Web applications use XML files for a variety of purposes, from configuration to full database functionality. User input is usually passed.

Broadcast to these files to customize the configuration or update the application database. This can be a security hazard if incorrect characters are not cleaned or validated before using user input. When no precautions are taken, malicious users can change configuration instructions, add new users (if the user list is maintained through XML files), gain higher privileges, and so on. The following proven vulnerable J2EE applications:

Document doc = docBuilder.newDocument (); Element rootElement = doc.createElement ("root"); doc.appendChild (rootElement); Element firstElement = doc.createElement ("first"); rootElement.appendChild (firstElement); Element childElement = doc.createElement ("child"); childElement.appendChild (doc.createTextNode (--User_Supplied_Text--)) / / un-sanitized text rootElement.appendChild (childElement)

The following demonstrates similar vulnerable .NET applications:

String nodeText = request.getParameter ("node"); XmlWriterSettings settings = new XmlWriterSettings (); writer = XmlWriter.Create (m_Document, settings); writer.WriteElementString ("newNode", nodeText); / / un-sanitized text writer.WriteEndElement ()

In this code, for example, user input is propagated to the XML file without proper cleanup. Depending on how your application uses XML files, this vulnerability can be exploited in a variety of ways.

0x02 threat impact

Because dangerous character cleanup is not performed correctly on user input, the worst-case scenario of this attack depends on the page context modified by the client, which may break the application logic

The idea of 0x03 repair

The remedy for several problems lies in cleaning up user input. By verifying that user input does not contain dangerous characters, it is possible to prevent malicious users from causing the application to perform unplanned tasks, such as launching arbitrary SQL queries, embedding Javascript code to be executed on the client, running various operating system commands, and so on.

1 it is recommended to filter the character [1] | (vertical bar symbol)

[2] & (& symbol)

[3]; (semicolon)

[4] $(dollar sign)

[5]% (percentage symbol)

[6] @ (at symbol)

[7]'(single quotation mark)

[8] "(quotation marks)

[9]\'(backslash escapes single quotation marks)

[10]\ "(backslash escape quotation marks)

[11] (angle brackets)

[12] () (parentheses)

[13] + (plus sign)

[14] CR (carriage return, ASCII 0x0d)

[15] LF (line feed, ASCII 0x0a)

[16], (comma)

[17]\ (backslash)

The following sections describe various issues, proposed revisions to them, and dangerous characters that may trigger them:

2 SQL injection and SQL blind injection

a. Ensure that the values and types entered by the user (such as Integer, Date, etc.) are valid and meet application expectations.

b. Use stored procedures to abstract data access so that users do not directly access tables or views. When using stored procedures, use the ADO command object to implement them to reinforce variable types.

c. Clean up input to exclude context change symbols, such as:

[1]'(single quotation mark)

[2] "(quotation marks)

[3]\'(backslash escape single quotation marks)

[4]\ "(backslash escape quotation marks)

[5]) (closing parentheses)

[6]; (semicolon)

3 cross-site scripting

a. Clean up user input and filter out the JavaScript code. We recommend that you filter the following characters:

[1] (angle brackets)

[2] "(quotation marks)

[3]'(single quotation mark)

[4]% (percentage symbol)

[5]; (semicolon)

[6] () (parentheses)

[7] & (& symbol)

[8] + (plus sign)

b. If you want to revise the variant, please refer to MS article 821349

c. For UTF-7 attacks: [-] if possible, it is recommended that you encode a specific character set (using the 'Content-Type' header or flag).

4 HTTP response Segmentation

Clean up user input (at least those embedded later in the HTTP response) make sure that the input does not contain malicious characters, such as:

[1] CR (carriage return, ASCII 0x0d)

[2] LF (newline, ASCII 0x0a) remote command execution: cleans up input to exclude symbols that are meaningful for executing operating system commands, such as:

[1] | (vertical bar symbol)

[2] & (& symbol)

[3]; (semicolon)

5 execute the shell command

a. Never pass unchecked user input to Perl commands like eval (), open (), sysopen (), system (), and so on.

b. Make sure that the input does not contain malicious characters, such as:

[1] $(dollar sign)

[2]% (percentage symbol)

[3] @ (at symbol)

XPath injection: cleans up input to exclude context change symbols, such as:

[1]'(single quotation mark)

[2] "(quotation marks), etc.

6 LDAP injection

a. Use positive validation. Alphanumeric filtering (A.. Z ·a.. z ·0.. 9) is suitable for most LDAP queries.

b. Special LDAP characters that should be filtered or escaped:

[1] A space or "#" character at the beginning of a string

[2] the space character at the end of the string

[3], (comma)

[4] + (plus sign)

[5] "(quotation marks)

[6]\ (backslash)

[7] (angle brackets)

[8]; (semicolon)

[9] () (parentheses)

7 MX injection

Special MX characters should be filtered out:

[1] CR (carriage return, ASCII 0x0d)

[2] LF (newline, ASCII 0x0a) record forgery:

Special record characters should be filtered out:

[1] CR (carriage return, ASCII 0x0d)

[2] LF (line feeds, ASCII 0x0a)

[3] BS (backspace, ASCII 0x08)

8 ORM injection

a. Ensure that the values and types entered by the user (such as Integer, Date, etc.) are valid and meet application expectations.

b. Use stored procedures to abstract data access so that users do not directly access tables or views. c. Use parameterized query API

d. Clean up input to exclude context change symbols, for example: (*):

[1]'(single quotation mark)

[2] "(quotation marks)

[3]\'(backslash escape single quotation marks)

[4]\ "(backslash escape quotation marks)

[5]) (closing parentheses)

[6]; (semicolon)

(*) this applies to SQL. Advanced query languages may require different cleanup mechanisms.

General recommendations of 0x04 Asp.Net1

[1] We recommend that you upgrade your server to .NET Framework 2.0 (or later), which itself includes security checks against cross-site scripting attacks.

[2] you can use validation controls to add input validation to the Web form page. Validation controls provide easy-to-use mechanisms for all common types of standard validation (for example, testing whether the validation date is valid or whether the validation value is in range). In addition, validation controls also support custom writing validation, which allows you to completely customize how error messages are displayed to users. Validation controls can be used with any control handled in the Web form page class file, including HTML and Web server controls.

2 ensure that the user input contains only valid values

[1] "RangeValidator": check whether the user entry (value) is between the specified upper and lower bounds. You can check the range within paired numbers, alphabetic characters, and dates.

[2] "RegularExpressionValidator": check whether the entry matches the pattern defined by the regular expression. This type of validation enables you to check predictable character sequences, such as social security numbers, e-mail addresses, phone numbers, postal codes, and so on. Examples of regular expressions that help prevent cross-site scripting:

-A regular expression that can reject basic cross-site scripting variants may be as follows: ^ ([^ 0) {$pass = true;} return $pass;} if (validateRequired ($fieldName)) {/ / fieldName is valid, continue processing request} [2] field data type

The field data types and input parameters in the entered Web application are poor. For example, all HTTP request parameters or cookie values are of type "string". The developer is responsible for verifying that the data type entered is correct.

[3] Field length

Always ensures that input parameters (HTTP request parameters or cookie values) have minimum and / or maximum length limits.

[4] Field range

Always make sure that the input parameters are within the scope defined by the functional requirements.

[5] Field option

Web applications typically show users a set of options to choose from (for example, using SELECT HTML tags), but cannot perform server-side validation to ensure that the selected value is one of the allowed options. Keep in mind that malicious users can easily modify any option value. Always validate the selected user value against the allowed options defined by the functional requirements.

[6] Field mode

Always check whether the user input matches the pattern defined by the functional requirements. For example, if the userName field should only allow alphanumeric characters and is case-insensitive, use the following regular expression: ^ [a-zA-Z0-9] + $

[7] cookie value

The same validation rules that apply to cookie values (as described above) depend on the application requirements (such as validation required values, validation length, and so on).

[8] HTTP response

[8-1] filtering user input to protect applications from cross-site scripting, developers should clean up HTML by converting sensitive characters to their corresponding character entities. These are HTML sensitive characters:

"'%;) (& + PHP contains some automated cleanup utility functions, such as htmlentities ():

$input = htmlentities ($input, ENT_QUOTES, 'UTF-8')

In addition, to avoid UTF-7 variants of "cross-site scripting", you should explicitly define the Content-Type header for the response, such as:

[8-2] protect cookie

When storing sensitive data in cookie and transmitting it over SSL, be sure to set the cookie security flag in the HTTP response first. This will instruct the browser to use the cookie only through a SSL connection. To protect cookie, you can use the following code example:

The above is all the content of the article "sample Analysis of XML injection". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.