0x01 SQL Injection Caused by IMPROPER JDBC concatenation
There are two JDBC methods for executing SQL statements: PrepareStatement and Statement. The difference between the two methods is that PrepareStatement precompiles the SQL Statement, while Statement needs to be compiled each time it is executed. Increases system overhead.
Theoretically, the efficiency and security of a PrepareStatement will be better than that of a Statement, but that doesn’t mean there won’t be problems.
The following is an example of executing an SQL Statement using Statement
String sql = "select * from user where id ="+req.getParameter("id");
PrintWriter out = resp.getWriter();
out.println("Statement Demo");
out.println("SQL: "+sql);
try {
Statement st = conn.createStatement();
ResultSet rs = st.executeQuery(sql);
Copy the code
Select * from user where id = 1 or 1 = 2; select * from user where id = 1 or 1 = 2;
Is the PreqareStatement method supported? Placeholding variable bits and filling in values during precompilation builds a complete SQL statement, thus avoiding SQL injection.
Sometimes, however, developers will simply concatenate SQL statements for convenience, so there will still be SQL injection, as shown in the code below.
String sql = "select * from user where id ="+req.getParameter("id");
PrintWriter out = resp.getWriter();
out.println("prepareStatement Demo");
out.println("SQL: "+sql);
try {
PreparedStatement pst = conn.prepareStatement(sql);
ResultSet rs = pst.executeQuery();
Copy the code
In this case, if you use or 1 = 1, you can still determine that SQL injection exists, but if you use? As placeholders, the value of the entered field is subject to strict type checking, effectively avoiding SQL injection, as shown in the code below.
PrintWriter out = resp.getWriter();
out.println("prepareStatement Demo");
String sql = "select * from user where id = ?";
out.println(sql);
try {
PreparedStatement pstt = conn.prepareStatement(sql);
// The parameter is mandatory as an integer
pstt.setInt(1, Integer.parseInt(req.getParameter("id")));
ResultSet rs = pstt.executeQuery();
while (rs.next()){
Copy the code
0x02 Improper use of framework causes SQL injection
Often the framework has a built-in defense against SQL injection, but there is still a risk of SQL injection if the framework is not used properly in the development.
1. MyBatis framework
The idea of MyBatis is to compile SQL statements into the configuration file to avoid SQL statements appearing in a large number of codes and facilitate the modification and configuration of SQL statements.
${} MyBatis uses parameterType to add parameters to SQL statements. ${} MyBatis uses parameterType to add parameters to SQL statements.
${} : SQL concatenation symbol. Directly concatenates the input statement into the SQL statement. To avoid SQL injection problems, manually add filters
#{} : placeholders that automatically enclose single quotes around input statements during data parsing to avoid SQL injection
In MyBatis, if ${} is used without filtering, SQL injection will be generated, while using #{} can avoid SQL injection.
2. Hibernate framework
Hibernate is the mainstream Java database persistence framework, which uses Hibernate query statement (HQL) injection.
HQL queries are parsed from the Hibernate engine, so errors can come from the database or the Hibernate engine.
HQL and SQL:
The cause of HQL injection is the same as that of SQL injection. Using the syntax of concatenated HQL statements may cause SQL injection
Query query = session.createQuery("from User where name='"+queryString+"'");
Copy the code
However, due to syntax, HQL injection has certain limitations on vulnerability exploitation, such as the inability to use federated query, cross-database table lookup, and command execution.
Hibernate injection, here as a simple understanding of the time to review the attention can be.
Reference article:
www.redhatzone.com/ask/article…
Blog.csdn.net/qq_36594628…
Original link:
www.teamssix.com/211117-0916…
For more information, please follow my personal wechat official account: TeamsSix