SQL Injection occurs when data input for example by a user is interpreted as a SQL command rather than normal data by the backend database. This is an extremely common vulnerability and its successful exploitation can have critical implications. Netsparker confirmed the vulnerability by executing a test SQL Query on the back-end database. In these tests, SQL Injection was not obvious but the different responses from the page based on the injection test allowed us to identify and confirm the SQL Injection.
Impact
Depending on the backend database, the database connection settings and the operating system, an attacker can mount one or more of the following type of attacks successfully:
Reading, Updating and Deleting arbitrary data from the database
Executing commands on the underlying operating system
Reading, Updating and Deleting arbitrary tables from the database
Actions to Take
See the remedy for solution.
If you are not using a database access layer (DAL), consider using one. This will help you to centralise the issue. You can also use an ORM (object relational mapping). Most of the ORM systems use only parameterised queries and this can solve the whole SQL Injection problem.
Locate the all dynamically generated SQL queries and convert them to parameterised queries. (If you decide to use a DAL/ORM change all legacy code to use these new libraries)
Use your weblogs and application logs to see if there was any previous but undetected attack to this resource.
Remedy
A robust method for mitigating the threat of SQL Injection based vulnerabilities is to use parameterized queries (prepared statements). Almost all modern languages provide built in libraries for this. Wherever possible do not create dynamic SQL queries or SQL queries with string concatenation.
Required Skills for Successful Exploitation
There are numerous freely available tools to exploit SQL Injection vulnerabilities. This is a complex area with many dependencies, however it should be noted that the numerous resources available in this area have raised both attacker awareness of the issues and their ability to discover and leverage them. SQL Injection is one of the most common web application vulnerabilities.
SQL Injection occurs when data input for example by a user is interpreted as a SQL command rather than normal data by the backend database. This is an extremely common vulnerability and its successful exploitation can have critical implications. Netsparker confirmed the vulnerability by executing a test SQL Query on the back-end database.
Impact
Depending on the backend database, the database connection settings and the operating system, an attacker can mount one or more of the following type of attacks successfully:
Reading, Updating and Deleting arbitrary data from the database
Executing commands on the underlying operating system
Reading, Updating and Deleting arbitrary tables from the database
Actions to Take
See the remedy for solution.
If you are not using a database access layer (DAL), consider using one. This will help you to centralise the issue. You can also use an ORM (object relational mapping). Most of the ORM systems use only parameterised queries and this can solve the whole SQL Injection problem.
Locate all of the dynamically generated SQL queries and convert them to parameterised queries (If you decide to use a DAL/ORM, change all legacy code to use these new libraries)
Use your weblogs and application logs to see if there was any previous but undetected attack to this resource.
Remedy
A robust method for mitigating the threat of SQL Injection based vulnerabilities is to use parameterized queries (prepared statements). Almost all modern languages provide built in libraries for this. Wherever possible do not create dynamic SQL queries or SQL queries with string concatenation.
Required Skills for Successful Exploitation
There are numerous freely available tools to exploit SQL Injection vulnerabilities. This is a complex area with many dependencies, however it should be noted that the numerous resources available in this area have raised both attacker awareness of the issues and their ability to discover and leverage them. SQL Injection is one of the most common web application vulnerabilities.
'+(select 1 and row(1,1)>(select count(*),concat(CONCAT(CHAR(95),CHAR(33),CHAR(64),CHAR(52),CHAR(100),CHAR(105),CHAR(108),CHAR(101),CHAR(109),CHAR(109),CHAR(97)),0x3a,floor(rand()*2))x from (select 1 union select 2)a group by x limit 1))+'
Extracted Data
5.0.45
Request
GET /engine.php?ac='%2B(select+1+and+row(1%2c1)%3e(select+count(*)%2cconcat(CONCAT(CHAR(95)%2CCHAR(33)%2CCHAR(64)%2CCHAR(52)%2CCHAR(100)%2CCHAR(105)%2CCHAR(108)%2CCHAR(101)%2CCHAR(109)%2CCHAR(109)%2CCHAR(97))%2c0x3a%2cfloor(rand()*2))x+from+(select+1+union+select+2)a+group+by+x+limit+1))%2B' HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322) Cache-Control: no-cache Host: dce.sapha.com Cookie: sapha_tst_2546=TRUE; sapha_tst_2546NS_NO=TRUE Accept-Encoding: gzip, deflate
</td></tr></table><b>Database error on host '192.168.50.20', db 'sapha_core', user 'www', object 'globalDB':</b> Invalid SQL: select SQL_CACHE * from site_options where site_ID = ''+(select 1 and row(1,1)>(select count(*),concat(CONCAT(CHAR(95),CHAR(33),CHAR(64),CHAR(52),CHAR(100),CHAR(105),CHAR(108),CHAR(101),CHAR(109),CHAR(109),CHAR(97)),0x3a,floor(rand()*2))x from (select 1 union select 2)a group by x limit 1))+''<br><b>MySQL Error</b>: 1062 (Duplicate entry '_!@4dilemma:0' for key 1)<br>Session halted.
SQL Injection occurs when data input for example by a user is interpreted as a SQL command rather than normal data by the backend database. This is an extremely common vulnerability and its successful exploitation can have critical implications. Even though Netsparker believes that there is a SQL Injection in here it could not confirm it. There can be numerous reasons for Netsparker not being able to confirm this. We strongly recommend investigating the issue manually to ensure that it is an SQL Injection and that it needs to be addressed. You can also consider sending the details of this issue to us, in order that we can address this issue for the next time and give you a more precise result.
Impact
Depending on the backend database, database connection settings and the operating system, an attacker can mount one or more of the following type of attacks successfully:
Reading, Updating and Deleting arbitrary data from the database
Executing commands on the underlying operating system
Reading, Updating and Deleting arbitrary tables from the database
Actions to Take
See the remedy for solution.
If you are not using a database access layer (DAL) within the architecture consider its benefits and implement if appropriate. As a minimum the use of s DAL will help centralize the issue and its resolution. You can also use an ORM (object relational mapping). Most ORM systems use parameterized queries and this can solve many if not all SQL Injection based problems.
Locate all of the dynamically generated SQL queries and convert them to parameterised queries. (If you decide to use a DAL/ORM, change all legacy code to use these new libraries)
Monitor and review weblogs and application logs in order to uncover active or previous exploitation attempts.
Remedy
A very robust method for mitigating the threat of SQL Injection based vulnerabilities is to use parameterized queries (prepared statements). Almost all modern languages provide built in libraries for this. Wherever possible do not create dynamic SQL queries or SQL queries with string concatenation.
Required Skills for Successful Exploitation
There are numerous freely available tools to test for SQL Injection vulnerabilities. This is a complex area with many dependencies, however it should be noted that the numerous resources available in this area have raised both attacker awareness of the issues and their ability to discover and leverage them. SQL Injection is one of the most common web application vulnerabilities.
</td></tr></table><b>Database error on host '192.168.50.20', db 'sapha_core', user 'www', object 'globalDB':</b> Invalid SQL: select SQL_CACHE * from site_options where site_ID = ''+ (select convert(int,CHAR(95)+CHAR(33)+CHAR(64)+CHAR(50)+CHAR(100)+CHAR(105)+CHAR(108)+CHAR(101)+CHAR(109)+CHAR(109)+CHAR(97)) FROM syscolumns) +''<br><b>MySQL Error</b>: 1064 (You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'int,CHAR(95)+CHAR(33)+CHAR(64)+CHAR(50)+CHAR(100)+CHAR(105)+CHAR(108)+CHAR(101)+' at line 1)<br>Session halted.
XSS (Cross-site Scripting) allows an attacker to execute a dynamic script (Javascript, VbScript) in the context of the application. This allows several different attack opportunities, mostly hijacking the current session of the user or changing the look of the page by changing the HTML on the fly to steal the user's credentials. This happens because the input entered by a user has been interpreted as HTML/Javascript/VbScript by the browser.
XSS targets the users of the application instead of the server. Although this is a limitation, since it allows attackers to hijack other users' session, an attacker might attack an administrator to gain full control over the application.
Impact
There are many different attacks that can be leveraged through the use of XSS, including:
Hi-jacking users' active session
Changing the look of the page within the victims browser.
Mounting a successful phishing attack.
Intercept data and perform man-in-the-middle attacks.
Remedy
The issue occurs because the browser interprets the input as active HTML, Javascript or VbScript. To avoid this, all input and output from the application should be filtered. Output should be filtered according to the output format and location. Typically the output location is HTML. Where the output is HTML ensure that all active content is removed prior to its presentation to the server.
Prior to sanitizing user input, ensure you have a pre-defined list of both expected and acceptable characters with which you populate a white-list. This list needs only be defined once and should be used to sanitize and validate all subsequent input.
There are a number of pre-defined, well structured white-list libraries available for many different environments, good examples of these include, OWASP Reform and Microsoft Anti Cross-site Scripting libraries are good examples.
</td></tr></table><b>Database error on host '192.168.50.20', db 'sapha_core', user 'www', object 'globalDB':</b> Invalid SQL: select SQL_CACHE * from site_options where site_ID = ''"--></style></script><script>netsparker(0x0000E0)</script>'<br><b>MySQL Error</b>: 1064 (You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '"--></style></script><script>netsparker(0x0000E0)</script>'' at line 1)<br>Session halted.
Cookie was not marked as HTTPOnly. HTTPOnly cookies can not be read by client-side scripts therefore marking a cookie as HTTPOnly can provide an additional layer of protection against Cross-site Scripting attacks..
Impact
During a Cross-site Scripting attack an attacker might easily access cookies and hijack the victim's session.
Actions to Take
See the remedy for solution
Consider marking all of the cookies used by the application as HTTPOnly (After these changes javascript code will not able to read cookies.
Remedy
Mark the cookie as HTTPOnly. This will be an extra layer of defence against XSS. However this is not a silver bullet and will not protect the system against Cross-site Scripting attacks. An attacker can use a tool such as XSS Tunnel to bypass HTTPOnly protection.
Netsparker identified that the target web server is an Apache server. This was disclosed through the HTTP response. This information can help an attacker to gain a greater understanding of the systems in use and potentially develop further attacks targeted at the specific version of Apache.
Impact
An attacker can search for specific security vulnerabilities for the version of Apache identified within the SERVER header.
Remedy
Configure your web server to prevent information leakage from the SERVER header of its HTTP response.
Netsparker identified that the target web server is disclosing the PHP version in use through the HTTP response. This information can help an attacker to gain a greater understanding of the systems in use and potentially develop further attacks targeted at the specific version of PHP.
Impact
An attacker can look for specific security vulnerabilities for the version identified. Also the attacker can use this information in conjunction with the other vulnerabilities in the application or the web server.
The error message may disclose sensitive information and this information can be used by an attacker to mount new attacks or to enlarge the attack surface. In rare conditions this may be a clue for an SQL Injection vulnerability. Most of the time Netsparker will detect and report that problem separately.
Remedy
Do not provide any error messages on production environments. Save error messages with a reference number to a backend storage such as a text file or database, then show this number and a static user-friendly error message to the user.
</td></tr></table><b>Database error on host '192.168.50.20', db 'sapha_core', user 'www', object 'globalDB':</b> Invalid SQL: select SQL_CACHE * from site_options where site_ID = ''& ping -n 26 127.0.0.1 &'<br><b>MySQL Error</b>: 1064 (You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '26 127.0.0.1 &'' at line 1)<br>Session halted.
Netsparker discovered an internal IP address in the page. It was not determined if the IP address was that of the system itself or that of an internal network.
Impact
This kind of information can be useful for an attacker when combined with other vulnerabilities.
Remedy
First ensure that this is not a false positive. Due to the nature of the issue. Netsparker could not confirm that this IP address was actually the real internal IP address of the target web server or internal network. If it is then consider removing it.
</td></tr></table><b>Database error on host '192.168.50.20', db 'sapha_core', user 'www', object 'globalDB':</b> Invalid SQL: select SQL_CACHE * from site_options where site_ID = ''& ping -n 26 127.0.0.1 &'<br><b>MySQL Error</b>: 1064 (You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '26 127.0.0.1 &'' at line 1)<br>Session halted.
Netsparker identified that the target web site is using a MySQL Server. This is generally not a security issue and is reported here for information purposes.
Impact
This issue is reported as additional information only, there is no direct impact arising from this issue.
</td></tr></table><b>Database error on host '192.168.50.20', db 'sapha_core', user 'www', object 'globalDB':</b> Invalid SQL: select SQL_CACHE * from site_options where site_ID = ''+(select 1 and row(1,1)>(select count(*),concat(CONCAT(CHAR(95),CHAR(33),CHAR(64),CHAR(52),CHAR(100),CHAR(105),CHAR(108),CHAR(101),CHAR(109),CHAR(109),CHAR(97)),0x3a,floor(rand()*2))x from (select 1 union select 2)a group by x limit 1))+''<br><b>MySQL Error</b>: 1062 (Duplicate entry '_!@4dilemma:0' for key 1)<br>Session halted.
