SQL_Injection issue exists @ root/register.jsp in branch master
*The application's stmt.executeQuery method executes an SQL query with executeQuery, at line 30 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input ""username""; this input is then read by the = method at line 6 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.executeQuery method executes an SQL query with executeQuery, at line 24 of root\password.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input ""username""; this input is then read by the = method at line 6 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.executeQuery method executes an SQL query with executeQuery, at line 29 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input ""username""; this input is then read by the = method at line 6 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.execute method executes an SQL query with execute, at line 59 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input getValue; this input is then read by the cookie.getValue method at line 51 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.execute method executes an SQL query with execute, at line 60 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input getValue; this input is then read by the cookie.getValue method at line 51 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.execute method executes an SQL query with execute, at line 59 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input getCookies; this input is then read by the request.getCookies method at line 46 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.execute method executes an SQL query with execute, at line 60 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input getCookies; this input is then read by the request.getCookies method at line 46 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.executeQuery method executes an SQL query with executeQuery, at line 29 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input ""password1""; this input is then read by the = method at line 7 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.executeQuery method executes an SQL query with executeQuery, at line 30 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input ""password1""; this input is then read by the = method at line 7 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.*
shaulco
commented
1 year ago
SQL_Injection issue exists @ root/register.jsp in branch master
*The application's stmt.executeQuery method executes an SQL query with executeQuery, at line 30 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input ""username""; this input is then read by the = method at line 6 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.executeQuery method executes an SQL query with executeQuery, at line 24 of root\password.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input ""username""; this input is then read by the = method at line 6 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.executeQuery method executes an SQL query with executeQuery, at line 29 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input ""username""; this input is then read by the = method at line 6 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.execute method executes an SQL query with execute, at line 59 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input getValue; this input is then read by the cookie.getValue method at line 51 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.execute method executes an SQL query with execute, at line 60 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input getValue; this input is then read by the cookie.getValue method at line 51 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.execute method executes an SQL query with execute, at line 59 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input getCookies; this input is then read by the request.getCookies method at line 46 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.execute method executes an SQL query with execute, at line 60 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input getCookies; this input is then read by the request.getCookies method at line 46 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.executeQuery method executes an SQL query with executeQuery, at line 29 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input ""password1""; this input is then read by the = method at line 7 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.
The application's stmt.executeQuery method executes an SQL query with executeQuery, at line 30 of root\register.jsp. The application constructs this SQL query by embedding an untrusted string into the query without proper sanitization. The concatenated string is submitted to the database, where it is parsed and executed accordingly.An attacker would be able to inject arbitrary syntax and data into the SQL query, by crafting a malicious payload and providing it via the input ""password1""; this input is then read by the = method at line 7 of root\register.jsp. This input then flows through the code, into a query and to the database server - without sanitization.This may enable an SQL Injection attack.*
Severity: High
CWE:89
Checkmarx
Training Recommended Fix
Lines: 51 6 7 46
Code (Line #51):
Code (Line #6):
Code (Line #7):
Code (Line #46):