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.
A Cookie was not marked as secure and transmitted over HTTPS. This means the cookie could potentially be stolen by an attacker who can successfully intercept and decrypt the traffic or following a successful MITM (Man in the middle) attack.
Impact
This cookie will be transmitted over a HTTP connection, therefore if this cookie is important (such as a session cookie) an attacker might intercept it and hijack a victim's session. If the attacker can carry out a MITM attack, he/she can force victim to make a HTTP request to steal the cookie.
Actions to Take
See the remedy for solution.
Mark all cookies used within the application as secure. (If the cookie is not related to authentication or does not carry any personal information you do not have to mark it as secure.))
Remedy
Mark all cookies used within the application as secure.
Required Skills for Successful Exploitation
To exploit this issue, the attacker needs to be able to intercept traffic. This generally requires local access to the web server or victim's network. Attackers need to be understand layer 2, have physical access to systems either as way points for the traffic, or locally (have gained access to) to a system between the victim and the web server.
Enter you email address or site name below and click Submit and we will send you a new password<br /> <input id="txtEmail" name="txtEmail" type="text" value="" style="width:300px" onblur="validatePresent(this,'msg_email');" /><br /> <div id="msg_email"> </div> <span style="color:Red"> <span id='lblResult' ></span> </span> <br /> <input id='btnSubmit' name='btnSubmit' type="submit" value="Submit" onclick="return validatePresent(document.getElementById('php:txtEmail'),'msg_email');" /> <input id='btnCancel' name='btnCancel' type="submit" value="Cancel" />
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.
Enter you email address or site name below and click Submit and we will send you a new password<br /> <input id="txtEmail" name="txtEmail" type="text" value="" style="width:300px" onblur="validatePresent(this,'msg_email');" /><br /> <div id="msg_email"> </div> <span style="color:Red"> <span id='lblResult' ></span> </span> <br /> <input id='btnSubmit' name='btnSubmit' type="submit" value="Submit" onclick="return validatePresent(document.getElementById('php:txtEmail'),'msg_email');" /> <input id='btnCancel' name='btnCancel' type="submit" value="Cancel" />
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.
Enter you email address or site name below and click Submit and we will send you a new password<br /> <input id="txtEmail" name="txtEmail" type="text" value="" style="width:300px" onblur="validatePresent(this,'msg_email');" /><br /> <div id="msg_email"> </div> <span style="color:Red"> <span id='lblResult' ></span> </span> <br /> <input id='btnSubmit' name='btnSubmit' type="submit" value="Submit" onclick="return validatePresent(document.getElementById('php:txtEmail'),'msg_email');" /> <input id='btnCancel' name='btnCancel' type="submit" value="Cancel" />
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.