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

In this article, the editor introduces in detail "what is the principle of Xpath injection attack in WEB security". The content is detailed, the steps are clear, and the details are handled properly. I hope that this article "what is the principle of Xpath injection attack in WEB security" can help you solve your doubts.

Xpath injection

3.11.1. Xpath definition

XPath injection attack refers to the ability to attach malicious XPath query code to URL, forms, or other information by making use of the loose input and fault tolerance of XPath parsers to gain access to permission information and change it. XPath injection attack is a new attack method against Web services, which allows attackers to obtain the complete content of an XML document through XPath query without knowing the relevant knowledge of XPath query in advance.

3.11.2. Principle of Xpath injection attack

XPath injection attacks are mainly through the construction of special inputs, which are often combinations of XPath syntax. These inputs will be passed into Web applications as parameters to perform the actions desired by intruders by executing XPath queries. The following is an example of the module in login authentication to illustrate the implementation principle of XPath injection attacks.

In the login authentication program of Web application, there are generally two parameters: user name (username) and password (password). The program will perform authorization operation through the user name and password submitted and entered by the user. If the verification data is stored in the XML file, the principle is to authorize access by looking up the results of the user name (username) and password (password) in the user table.

For example, the user.xml file is as follows:

Ben

Elmore

Abc

Test123

Shlomy

Gantz

Xyz

123test

The typical query statement in XPath is as follows:

/ / users/user [loginID/text () = 'xyz'and password/text () =' 123 test']

However, the following methods can be used to implement injection attacks to bypass authentication. If the user passes in a login and password, such as loginID = 'xyz' and password =' 123 testcards, the query returns true. But if the user passes in a value like'or 1, 1 or "=', then the query statement will also get the true return value, because the XPath query statement will eventually become the following code:

/ / users/user [loginID/text () = "or 1 or" = "and password/text () =" or 1 or "="]

This string logically causes the query to always return true and will always allow the attacker to access the system. An attacker can use XPath to dynamically manipulate XML documents in an application. After completing the login attack, you can obtain the highest privilege account and other important document information through XPath blind entry technology.

3.12

Logic vulnerabilities / business vulnerabilities

3.12.1. Brief introduction

Logic loophole refers to the loophole caused by some logic branch processing errors caused by lax logic of the program. In actual development, similar vulnerabilities often occur because developers have no security awareness at different levels, and internal testing is not in place in time for rapid business development.

3.12.2. Installation logic

● to see if you can bypass the decision to reinstall

● to see if you can use the installation file to get information

● to see if you can use the update function to obtain information.

3.12.3. Trade

3.12.3.1. Purchase

● modifies the price paid

● modifies the status of the payment

● modifies the purchase quantity to be negative

The amount modified by ● is negative.

● replay successful request

Improper handling of ● concurrent database lock

3.12.3.2. Business risk control

● swipes coupons.

● cashing out

3.12.4. Account

3.12.4.1. Register

● override registration

● attempted to repeat the user name

● registration traverses and guesses existing accounts

3.12.4.2. Log in

● collides with library

● account hijacking

● maliciously attempts to lock up an account with a password

3.12.4.3. Retrieve the password.

● resets any user password

After the ● password is reset, the new password is in the return packet

● Token authentication logic is on the front end

3.12.4.4. Modify the password

● ultra vires to change password

● changes the password without old password verification

3.12.5. Verification code

The strength of ● verification code is not enough.

● verification code has no time limit or has a long expiration time.

● CAPTCHA has no limit on the number of guesses

● CAPTCHA passes special parameters or does not pass parameters around

The ● verification code can be obtained directly from the return packet.

● CAPTCHA is not refreshed or invalid

The number of ● verification codes is limited.

The ● CAPTCHA is returned in the packet

● modified Cookie Bypass

● modified return packet Bypass

● graphic CAPTCHA can be recognized by OCR or machine learning

● CAPTCHA is used for SMS / mailbox bombing.

3.12.6. Session

● Session mechanism

● Session guess / blow up

● Session forgery

● Session leak

● Session Fixation

3.12.7. Ultra vires

The level of ● exceeds its authority

An attacker can access the resources of a user who has the same permissions as him

The permission type remains the same and the ID changes

● Vertical ultra vires

Low-level attackers can access the resources of high-level users

Permission ID unchanged, type changed

● Cross ultra vires

Permission ID change, type change

3.12.8. Random number security

● uses unsafe random number generators

● uses easily guessed factors such as time as seeds of random numbers.

3.12.9. Other

ID generation of ● users / orders / coupons is regular and can be enumerated

● interface has no permission and number of times.

Misuse of ● encryption algorithm

● execution order

● sensitive information disclosure

3.13

Configure security

● weak password

The number of bits is too low

Small character set

Is a commonly used password

Personal information related (mobile phone number, birthday name, user name)

Use keyboard mode as password

Leakage of ● sensitive files

.git

.svn

● database

Databases such as Mongo/Redis do not have passwords and do not restrict access

● encryption system

Store the private key on the client

● tripartite library / software

It was not updated in time after the vulnerability was made public.

After reading this, the article "what is the principle of Xpath injection attacks in WEB Security" has been introduced. If you want to master the knowledge of this article, you still need to practice and use it yourself. If you want to know more about related articles, please 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.