4 Common Web Vulnerabilities Expected to Surface in 2016

Laptop with coding on a screen
Common Web Vulnerabilities in 2016

Many of the cyber-crimes that have been highlighted in the past few years were made possible due to common web vulnerabilities. Adversaries are finding it easy to pinpoint flaws in web pages, making it trivial for even novice hackers to exploit them.

In this post, you’ll learn about four of the most common web vulnerabilities in websites and how they could be exploited by cyber criminals. Read the detailed description of these vulnerabilities below.

SQL Injection

The SQL injection is a vulnerability in which a hacker tries to exploit application code to corrupt or access database content. If the intruder succeeds, they’re able to modify the back-end database through malicious user input. The method of attack has been used to hit organizations like the WHO (World Health Organization).

Cyber criminals are also using tools to automate the process of testing URLs to see which endpoints are vulnerable. An example is sqlmap– this tool will crawl web pages on a site, similar to how search engine crawlers function and look for input forms on those web pages. It will then input details that might result in MySQL syntax errors.

It’s thought that this vulnerability was the reason behind the attacks on Sony’s PlayStation database; it enabled hackers to inject unauthorized code. After gaining access via unsanitized input, hackers have unlimited privileges and sensitive data at hand to cause havoc. To prevent these attacks, web developers need to apply proper validation/filtration on all entry points.

XSS (Cross-Site Scripting)

This vulnerability enables cyber criminals to insert Javascript tags in trusted web pages. After the insertion, they can alter the contents of the web page and redirect user credentials to remote servers (controlled by them or their partners).

When the user loads the page, the Javascript runs, and the hacker gains elevated access to session cookies, sensitive content, and several other user-side objects. This popular vulnerability has been used to steal credit card numbers and conduct unauthorized financial transactions. A report revealed that XSS is the easiest way to hack into a website.

According to WhiteHat Security’s Whitepaper, there is a 67 percent chance that sites have at least one XSS (Cross Site Scripting) vulnerability, over 11 percent greater than any other language. Apart from redirecting users’ data to malicious servers, XSS is pretty popular for hijacking user sessions and defacing government websites.

On a positive note, new versions of leading web browsers are including sophisticated checks against XSS. Web developers can also design code to validate inputs before they’re used on web pages.

File Inclusion

The File Inclusion vulnerability is exploited by hackers to gain unauthorized access to sensitive data on web servers and inject malicious files by utilizing the “include” functionality. Bad input validation is the prime reason for this vulnerability, whereas, without proper validation, the user’s input (including commands) is passed to the file.

File inclusion attacks can be in the form of remote file inclusion (RFI) or local file inclusion (LFI). RFI enables hackers to inject and launch a remotely hosted file via a script by planting it in the targeted page. RFI can be used to run malicious codes on both the server and the client side.

LFI is when the user input includes the path to the file that needs to be included. Without sanitization, hackers can give default names to files and gain unauthorized access. Hackers can also utilize directory traversal characters and access other directories to retrieve sensitive files and conduct an attack.

From log files, hackers will harvest useful information such as usernames and passwords. They can also multiply commands by combining the file inclusion flaw with other attack vectors, such as log injection.

File inclusion attacks could be prevented by avoiding the use of arbitrary input data in the literal file include requests. And by all means, unsecured data should never be allowed to enter a secure context.

Broken Authentication & Session Management

Web pages have to handle authentication requests and create sessions to keep track of requests as HTTP doesn’t have this capability. Unless the user is protecting all session identifiers and credentials against disclosure from vulnerabilities, hackers can hijack the identity of the user.

Apart from prime mechanism flaws, further weaknesses are introduced via ancillary functions including timeout, secret questions, password management, and log out.

For instance, when Microsoft wanted to remove a vulnerability in Hotmail that enabled malicious Javascript programmers to exploit user passwords, it was discovered that the flaw was prone to emails including Trojans that altered the user interface of Hotmail accounts. Users had to re-enter their passwords repeatedly; these details were unwittingly sent to hackers.

Sometimes, this vulnerability occurs when companies customize authentication. They inadvertently allow infiltration of sessions and adversaries utilize ID cookies to access legitimate user accounts.

At the user’s end, simply closing web browsers instead of logging out can give rise to this vulnerability. Attackers will access the same browser after a while as that browser will still be authenticated. To prevent broken authentication and session management attacks, web developers should integrate SSL (secured sockets layer) to encrypt the session. Also, invalidated session IDs should never be reused.

Final Thoughts

The vulnerabilities mentioned above are the most common ones in web applications, servers, and pages.

They’ve been around for a while along with their preventive measures, but until web developers prioritize the security of web pages, attackers will continue to take advantage of these flaws to commit cyber-espionage, theft, and malicious attacks.

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Cloudbric.



Leave a Reply

Your email address will not be published.