Directory
-
- SQL Injection(mitigation)
- Demonstration case:
-
- Javaweb-SQL injection attack-precompilation mechanism bypass
- Javaweb-Authentication Attack-JWT Modification Forgery Attack
jwt encryption and decryption: https://jwt.io/#debugger-io
Through the early study of WEB vulnerabilities, I have mastered the principles and utilization of most security vulnerabilities. However, due to the differences in various scripting language development environments, new security issues will exist. Among them, the mainstream scripting language types such as PHP, Java, and Python Development frameworks will vary.
When each scripting language develops its web program, regardless of its structure or the characteristics of its development language, these different conditions will cause some new problems. If PHP is prone to develop loopholes, Java is prone to develop loopholes. , is caused by differences in language characteristics and development situations. Most of the vulnerabilities are around PHP and Java. Of course, they are also available in the mainstream development framework of Python. Basically, after talking about PHP and Java, it is almost the same
Problems that appear on Java websites may not necessarily occur on PHP websites. Similarly, problems with PHP cannot occur on Java. However, some vulnerabilities are the same, such as XSS vulnerabilities, which will also occur in PHP. , also occurs in Java, and the exploits and principles are basically the same, because the characteristics of some vulnerabilities are not directly related to the environment.
When we talk about Java web security, we are talking about the different vulnerabilities between it and other scripts, such as PHP. We are mainly talking about this matter.
Access control is unique to Java, but rarely to PHP; in terms of authentication, the security issue of JWT tokens is also unique to Java, and is rarely seen in PHP. PHP has this function, but there will be no problems; component security is also different. Some vulnerabilities are unique and will not be as common as other scripts.
SQL Injection(mitigation)
Defending against sql injection actually involves injections such as session, parameter binding, and stored procedures.
//Using session defense, the session content cannot be modified by the user under normal circumstances.
select * from users where user = "'" + session.getAttribute("UserID") + "'";
The data obtained by the sql statement does not receive the data according to the data you send. It takes the data in the session, which is the data of the login cookie. The value inside is used as the login status. Generally, the session is stored in the other party’s server. It is not like Cookie, the session data on the other party’s server, is equivalent to not manipulating the data in the server. It cannot be forged. This method can prevent SQL injection. In fact, it is to get a fixed value from the server, not to let you When the website sends data, it will receive any data. This data is equivalent to being uncontrollable. This injection cannot achieve the target of our attack.
// Parameter binding method uses sql pre-compilation technology
String query = "SELECT * FROM users WHERE last_name = ?"; PreparedStatement statement = connection.prepareStatement(query); statement.setString(1, accountName); ResultSet results = statement.executeQuery();
If we send injection or code, it will execute your parameter content as a SQL command, which is equivalent to a string and has no meaning.
Precompilation is a very common situation in Java. It can also be used in PHP. It has an extension. Some PHP versions support precompilation.
The method mentioned above is not able to absolutely defend against SQL injection, but only mitigates it.
For example, the parameter binding method can be bypassed using the following method.
By using the case when statement, you can add a select statement to the orderExpression expression after order by.
The security issues in the Java precompilation mechanism can be used in case when. It has a prerequisite, which is order by insertion. That is, when it comes to the sorting function, the other party can inject even if it uses precompilation. If there is no order by, Then you can only find useless methods on the Internet, most of which are useless.
Java applications have fewer injections. The reason is that there are pre-made pre-compilers in it, which can protect against most SQL injection attacks. This is why when people use SRC to dig vulnerabilities, because many SRC targets Java applications, then you must look for injection. It’s difficult because one of its language features is more secure than PHP.
The SQL injection function of order by, the function of its SQL injection instruction is sorting, that is to say, an application of the other party’s operation. If it involves the sorting operation, from the black box attack test, it can be concluded that the other party’s SQL statement is If there is an operation of order by, then you can use it to bypass precompilation at this time. If you confirm that the other party does not have order by, then GG
Demo case:
Javaweb-SQL injection attack-precompilation mechanism bypass
#Understand the precompilation mechanism
https://www.cnblogs.com/klyjb/p/11473857.html
https://www.zhihu.com/gustion/43581628
#Refer to parameter binding bypass method case when injection
Javaweb-Authentication Attack-JWT Modification Forgery Attack
#Understand the JWT transmission process and verification mechanism
#Understand the JWT structure, encryption and decryption process and precautions
Notice:
The problem is, because the declaration content of JWT has changed, the signature needs to be regenerated, and a password is required to generate the signature. We don’t have a password? Don’t panic, let’s just remove the signature~Change the header to None
After changing the statement, you need to re-sign. The signature requires a key. None does not encrypt. If it does not encrypt, you can ignore the signature.
The signature is encrypted using a key. Without the key, the signature cannot be deduced. The header and statement can be reversed through base64 encryption and decryption.
During the HTTP transmission process, special symbols such as “=”, “+ “, “/” in Base64 encoding are usually easy to produce ambiguities through URL decoding, so URL-compatible Base64 URL encoding is produced.
What is JWT?
JSON web Token (JSON Web Token) is a cross-domain identity verification scheme. JWT does not encrypt the transmitted data, but can verify that the data has not been tampered with through digital signatures (but I doubt this after doing the WebGoat exercise below).
JWT is divided into three parts, header, claims, and signature. The three parts are separated by English periods. The content of the JWT is encoded in Base64URI.
Header
{
“alg”:”HS256″,
“typ”:”JWT”
}
alg
It is a parameter describing the algorithm used for the signature of this JWT. Common values are HS256 (default), HS512, etc. It can also be None. HS256 stands for HMAC SHA256.
type
Indicate that the type of this token is JWT
Claims
{<!-- -->
"exp": 1416471934,
"user_name": "user",
"scope": [
"read"
"write"
],
"authorities": [
"ROLE_ADMIN"
"ROLE_USER"
],
"client_id":"my-client-with-secret"
}
JWT fixed parameters are:
iss:issuer
exp:expiration time
sub:topic
aud:user
nbf: not available before
iat: release time
jti:JWT ID is used to identify the JWT
Signature
The server has a secret that will not be sent to the client. The header and declared content are encrypted with this secret using the algorithm specified in the header. The generated string is the signature of the JWT.
The following is a code example using HS256 to generate JWT
HMACSHA256(base64UrIEncode(header) + “.” +
base64UrIEncode(payload),secret)
1. The client logs in, and the username and password are sent to the server in the request.
2. (After confirming that the login information is correct) the server generates a JSON header and statement, writes the login information into the JSON statement (usually the password should not be written, because JWT is not encrypted), and uses secret to encrypt with the specified algorithm. Generate a JWT for this user. At this time, the server does not save login status information.
3. The server returns the JWT (via the response) to the client
4. The client will automatically write the JWT in the Authorization field of the HTTP request header during the user’s next session.
5. The server verifies the JWT. If the verification is successful, the user’s login status is confirmed.
6. The server returns a response
JWT is the identity information, so when we change the identity information, it is similar to the use of cookies to achieve administrator login as we talked about in the early stage. It is just that JWT is an encrypted string and we need to analyze and reverse it.
JWT not only determines the identity but also determines the transmission data. If this data involves database query, it will also lead to SQL injection. If it involves other things, it will lead to other vulnerabilities.
When logging in, you change your login user to admin, and then keep the same in the jwt data package. Then the other party will think that you are logged in as admin. After logging in, use the admin user to perform operations.