10 Most Common Web Security Vulnerabilities

Gergely has worked as lead developer for an Alexa Top 50 website serving several a million unique visitors each month.

SHARE

For all too many companies, it’s not until aftera security breach has occurred that web security best practices become a priority. During my years working as an IT Security professional, I have seen time and time again how obscure the world of web development security issues can be to so many of my fellow programmers.

An effective approach to web security threats must, by definition, be proactive and defensive. Toward that end, this post is aimed at sparking a security mindset, hopefully injecting the reader with a healthy dose of paranoia.

In particular, this guide focuses on 10 common and significant web security pitfalls to be aware of, including recommendations on how they can be mitigated. The focus is on the Top 10 Web Vulnerabilities identified by the Open Web Application Security Project (OWASP), an international, non-profit organization whose goal is to improve software security across the globe.

A little cyber security primer before we start – authentication and authorization

When speaking with other programmers and IT professionals, I often encounter confusion regarding the distinction between authorization and authentication. And of course, the fact the abbreviation auth is often used for both helps aggravate this common confusion. This confusion is so common that maybe this issue should be included in this post as “Common Web Vulnerability Zero”.

So before we proceed, let’s clarify the distinction between these two terms:

Authentication: Verifying that a person is (or at least appears to be) a specific user, since he/she has correctly provided their security credentials (password, answers to security questions, fingerprint scan, etc.).

Authorization: Confirming that a particular user has access to a specific resource or is granted permission to perform a particular action.

Stated another way, authentication is knowing who an entity is, while authorization is knowing what a given entity can do. With this in mind, let’s get into the top 10 internet security issues.

Common Web Security Mistake #1: Injection flaws

Injection flaws result from a classic failure to filter untrusted input. It can happen when you pass unfiltered data to the SQL server (SQL injection), to the browser (XSS – we’ll talk about this later), to the LDAP server (LDAP injection), or anywhere else. The problem here is that the attacker can inject commands to these entities, resulting in loss of data and hijacking clients’ browsers.

Anything that your application receives from untrusted sources must be filtered, preferably according to a whitelist. You should almost never use a blacklist, as getting that right is very hard and usually easy to bypass. Antivirus software products typically provide stellar examples of failing blacklists. Pattern matching does not work.

Prevention: The good news is that protecting against injection is “simply” a matter of filtering your input properly and thinking about whether an input can be trusted. But the bad news is that all input needs to be properly filtered, unless it can unquestionably be trusted (but the saying “never say never” does come to mind here).

In a system with 1,000 inputs, for example, successfully filtering 999 of them is not sufficient, as this still leaves one field that can serve as the Achilles heal to bring down your system. And you might think that putting an SQL query result into another query is a good idea, as the database is trusted, but if the perimeter is not, the input comes indirectly from guys with malintent. This is called Second Order SQL Injection in case you’re interested.

Since filtering is pretty hard to do right (like crypto), what I usually advise is to rely on your framework’s filtering functions: they are proven to work and are thoroughly scrutinized. If you do not use frameworks, you really need to think hard about whether not using them really makes sense in your server security context. 99% of the time it does not.

Common Web Security Mistake #2: Broken Authentication

This is a collection of multiple problems that might occur during broken authentication, but they don’t all stem from the same root cause.

Assuming that anyone still wants to roll their own authentication code in 2014 (what are you thinking??), I advise against it. It is extremely hard to get right, and there are a myriad of possible pitfalls, just to mention a few:

The URL might contain the session id and leak it in the referer header to someone else.

The passwords might not be encrypted either in storage or transit.

The session ids might be predictable, thus gaining access is trivial.

Session fixation might be possible.

Session hijacking might be possible, timeouts not implemented right or using HTTP (no SSL security), etc…

Prevention: The most straightforward way to avoid this web security vulnerability is to use a framework. You might be able to implement this correctly, but the former is much easier. In case you do want to roll your own code, be extremely paranoid and educate yourself on what the pitfalls are. There are quite a few.

Common Web Security Mistake #3: Cross Site Scripting (XSS)

This is a fairly widespread input sanitization failure (essentially a special case of common mistake #1). An attacker gives your web application JavaScript tags on input. When this input is returned to the user unsanitized, the user’s browser will execute it. It can be as simple as crafting a link and persuading a user to click it, or it can be something much more sinister. On page load the script runs and, for example, can be used to post your cookies to the attacker.

Prevention: There’s a simple web security solution: don’t return HTML tags to the client. This has the added benefit of defending against HTML injection, a similar attack whereby the attacker injects plain HTML content (such as images or loud invisible flash players) – not high-impact but surely annoying (“please make it stop!”). Usually, the workaround is simply converting all HTML entities, so that <script> is returned as &lt;script&gt;. The other often employed method of sanitization is using regular expressions to strip away HTML tags using regular expressions on < and >, but this is dangerous as a lot of browsers will interpret severely broken HTML just fine. Better to convert all characters to their escaped counterparts.

Common Web Security Mistake #4: Insecure Direct Object References

This is a classic case of trusting user input and paying the price in a resulting security vulnerability. A direct object reference means that an internal object such as a file or database key is exposed to the user. The problem with this is that the attacker can provide this reference and, if authorization is either not enforced (or is broken), the attacker can access or do things that they should be precluded from.

For example, the code has a download.php module that reads and lets the user download files, using a CGI parameter to specify the file name (e.g., download.php?file=something.txt). Either by mistake or due to laziness, the developer omitted authorization from the code. The attacker can now use this to download any system files that the user running PHP has access to, like the application code itself or other data left lying around on the server, like backups. Uh-oh.

Another common vulnerability example is a password reset function that relies on user input to determine whose password we’re resetting. After clicking the valid URL, an attacker can just modify the username field in the URL to say something like “admin”.

Incidentally, both of these examples are things I myself have seen appearing often “in the wild”.

Prevention: Perform user authorization properly and consistently, and whitelist the choices. More often than not though, the whole problem can be avoided by storing data internally and not relying on it being passed from the client via CGI parameters. Session variables in most frameworks are well suited for this purpose.

Common Web Security Mistake #5: Security misconfiguration

In my experience, web servers and applications that have been misconfigured are way more common than those that have been configured properly. Perhaps this because there is no shortage of ways to screw up. Some examples:

Running the application with debug enabled in production.

Having directory listing enabled on the server, which leaks valuable information.

Running outdated software (think WordPress plugins, old PhpMyAdmin).

Having unnecessary services running on the machine.

Not changing default keys and passwords. (Happens way more frequently than you’d believe!)

Revealing error handling information to the attackers, such as stack traces.

Prevention: Have a good (preferably automated) “build and deploy” process, which can run tests on deploy. The poor man’s security misconfiguration solution is post-commit hooks, to prevent the code from going out with default passwords and/or development stuff built in.

Common Web Security Mistake #6: Sensitive data exposure

This web security vulnerability is about crypto and resource protection. Sensitive data should be encrypted at all times, including in transit and at rest. No exceptions. Credit card information and user passwords should never travel or be stored unencrypted, and passwords should always be hashed. Obviously the crypto/hashing algorithm must not be a weak one – when in doubt, web security standards recommend AES (256 bits and up) and RSA (2048 bits and up).

And while it goes without saying that session IDs and sensitive data should not be traveling in the URLs and sensitive cookies should have the secure flag on, this is very important and cannot be over-emphasized.

In storage: This is harder. First and foremost, you need to lower your exposure. If you don’t need sensitive data, shred it. Data you don’t have can’t be stolen. Do not store credit card information ever, as you probably don’t want to have to deal with being PCI compliant. Sign up with a payment processor such as Stripe or Braintree. Second, if you have sensitive data that you actually do need, store it encrypted and make sure all passwords are hashed. For hashing, use of bcrypt is recommended. If you don’t use bcrypt, educate yourself on salting and rainbow tables.

And at the risk of stating the obvious, do not store the encryption keys next to the protected data. That’s like storing your bike with a lock that has the key in it. Protect your backups with encryption and keep your keys very private. And of course, don’t lose the keys!

Common Web Security Mistake #7: Missing function level access control

This is simply an authorization failure. It means that when a function is called on the server, proper authorization was not performed. A lot of times, developers rely on the fact that the server side generated the UI and they think that the functionality that is not supplied by the server cannot be accessed by the client. It is not as simple as that, as an attacker can always forge requests to the “hidden” functionality and will not be deterred by the fact that the UI doesn’t make this functionality easily accessible. Imagine there’s an /admin panel, and the button is only present in the UI if the user is actually an admin. Nothing keeps an attacker from discovering this functionality and misusing it if authorization is missing.

Prevention: On the server side, authorization must always be done. Yes, always. No exceptions or vulnerabilities will result in serious problems.

Common Web Security Mistake #8: Cross Site Request Forgery (CSRF)

This is a nice example of a confused deputy attack whereby the browser is fooled by some other party into misusing its authority. A 3rd party site, for example, can make the user’s browser misuse it’s authority to do something for the attacker.

In the case of CSRF, a 3rd party site issues requests to the target site (e.g., your bank) using your browser with your cookies / session. If you are logged in on one tab on your bank’s homepage, for example, and they are vulnerable to this attack, another tab can make your browser misuse its credentials on the attacker’s behalf, resulting in the confused deputy problem. The deputy is the browser that misuses its authority (session cookies) to do something the attacker instructs it to do.

Consider this example:

Attacker Alice wants to lighten target Todd’s wallet by transfering some of his money to her. Todd’s bank is vulnerable to CSRF. To send money, Todd has to access the following URL:

After this URL is opened, a success page is presented to Todd, and the transfer is done. Alice also knows, that Todd frequently visits a site under her control at blog.aliceisawesome.com, where she places the following snippet:

Upon visiting Alice’s website, Todd’s browser thinks that Alice links to an image, and automatically issues an HTTP GET request to fetch the picture, but this actually instructs Todd’s bank to transfer $1500 to Alice.

Incidentally, in addition to demonstrating the CSRF vulnerability, this example also demonstrates altering the server state with an idempotent HTTP GET request which is itself a serious vulnerability. HTTP GET requests must be idempotent (safe), meaning that they cannot alter the resource which is accessed. Never, ever, ever use idempotent methods to change the server state.

Fun fact: CSRF is also the method people used for cookie-stuffing in the past until affiliates got wiser.

Prevention: Store a secret token in a hidden form field which is inaccessible from the 3rd party site. You of course always have to verify this hidden field. Some sites ask for your password as well when modifying sensitive settings (like your password reminder email, for example), although I’d suspect this is there to prevent the misuse of your abandoned sessions (in an internet cafe for example).

Common Web Security Mistake #9: Using components with known vulnerabilities

The title says it all. I’d again classify this as more of a maintenance/deployment issue. Before incorporating new code, do some research, possibly some auditing. Using code that you got from a random person on GitHub or some forum might be very convenient, but is not without risk of serious web security vulnerability.

I have seen many instances, for example, where sites got owned (i.e., where an outsider gains administrative access to a system), not because the programmers were stupid, but because a 3rd party software remained unpatched for years in production. This is happening all the time with WordPress plugins for example. If you think they will not find your hidden phpmyadmin installation, let me introduce you to dirbuster.

The lesson here is that software development does not end when the application is deployed. There has to be documentation, tests, and plans on how to maintain and keep it updated, especially if it contains 3rd party or open source components.

Prevention:

Exercise caution. Beyond obviously using caution when using such components, do not be a copy-paste coder. Carefully inspect the piece of code you are about to put into your software, as it might be broken beyond repair (or in some cases, intentionally malicious—web security attacks are sometimes unwittingly invited in this way).

Stay up-to-date. Make sure you are using the latest versions of everything that you trust, and have a plan to update them regularly. At least subscribe to a newsletter of new security vulnerabilities regarding the product.

Common Web Security Mistake #10: Unvalidated redirects and forwards

This is once again an input filtering issue. Suppose that the target site has a redirect.php module that takes a URL as a GET parameter. Manipulating the parameter can create a URL on targetsite.com that redirects the browser to malwareinstall.com. When the user sees the link, they will see targetsite.com/blahblahblah which the user thinks is trusted and is safe to click. Little do they know that this will actually transfer them onto a malware drop (or any other malicious) page. Alternatively, the attacker might redirect the browser to targetsite.com/deleteprofile?confirm=1.

It is worth mentioning, that stuffing unsanitized user-defined input into an HTTP header might lead to header injection which is pretty bad.

Prevention: Options include:

Don’t do redirects at all (they are seldom necessary).

Have a static list of valid locations to redirect to.

Whitelist the user-defined parameter, but this can be tricky.

Epilogue

I hope that I have managed to tickle your brain a little bit with this post and to introduce a healthy dose of paranoia and website security vulnerability awareness.

The core takeaway here is that age-old software practices exist for a reason and what applied back in the day for buffer overflows, still apply for pickled strings in Python today. Security protocols help you write (more) correct programs, which all programmers should aspire to.

Please use this knowledge responsibly, and don’t test pages without permission!

Feedback on this post and its mitigation advice is welcome and appreciated. Future related posts are planned, particularly on the issue of distributed denial-of-service (DDoS) and old-school (not web) IT security vulnerabilities. If you have a specific request on what kind of web protection to write about, please feel free to contact me directly at [email protected]

Understanding the basics

What is an internet security threat?

Internet security threats are methods of abusing web technology to the detriment of a web site, its users, or even the internet at large. They arise from web sites that are misconfigured, that were inadvertently programmed with vulnerabilities, or that rely on components that are themselves vulnerable.

How do you redirect a URL?

Make sure that any redirects your site makes (via HTTP headers, meta tags, JavaScript, etc.) do not rely on user input, or if they do, that the user input is sanitized, for example via a whitelist.

What is the use of CSRF token?

A CSRF token lets a server know that the request came from the user of its own site, and not from some other web site the user is visiting. This is because it's passed with every request via a hidden form field, preventing malicious sites from acting on behalf of their viewers via CSRF attacks.

What is unvalidated input?

Also known as "dirty" or "untrusted" input, unvalidated input is any input that is sent to your server. Any piece of code that uses such input without sanitizing it first is a security vulnerability that can be turned against you, your users, and even innocent bystanders.

What do you mean by SQL injection?

SQL injection is when your code puts unvalidated input directly into an SQL statement, instead of using a parameterized query (i.e. one with placeholders.) Fortunately, SQL injection attacks are one of the easiest to mitigate, because parameterized query support is built into every database access library.

What does XSS exploit in a web application?

XSS exploits misguided implementations of a common web application "feature": to receive HTML from one user and present it to other users. Because unfiltered HTML can contain JavaScript, an attacker can then run code on other users' behalf when they next use the web application in question.

What is security misconfiguration?

Security misconfiguration often involves using defaults that should be changed: Keys and passwords, data and service access that's initially liberal for setup and testing convenience, and neglecting ongoing security updates.

What is broken access control?

This is when the server is not programmed to verify authorization for a given function. Often this comes from a "security through obscurity" mindset: It's falsely assumed that if a sensitive feature isn't shown to everyone, potential attackers will never find out about it.

What is sensitive data exposure?

Sensitive data exposure is when an app (either by its own flaw, or by an attacker's abuse of a vulnerability) reveals a user's private data (e.g. credit card numbers) to an unauthorized third party: Other users, business partners, employees, or the public.

Gergely is a versatile CTO with a wide variety of experience in a lot of different technologies. He is able to design systems from the ground up and carry them through their lifecycle. Having managed his own tech team, he does not shy away from managing others or advising business decisions.

Comments

LOL. We've been using Silent Breach for 5 years, but sure, based on the comment section of an online article, we'll switch to an anonymous hacker on the darkweb. Looking forward!

Anna Bailey

Thanks for the info. Now I am aware of these vulnerabilities. It's really nice to find this info.

NYGCI

Just thought I would comment and say awesome theme, did you code it on your own? Really looks excellent!
<a href="https://www.nygci.com/data-security-solutions-data-protection-services-india/">Data Protection Solutions in India</a>

joycehess

Nice blog very informative. For finding website vulnerabilities i suggest to use indusface.com.

finnich

It's a tedious work to catch all those false positives but once you have everything in place you can sleep with both eyes closed and, the next morning see in logs "bad-robots", massive downloaders or crap like that dying against the software firewall.

Nirmal Kant

Absolutely fantastic article. Covers lots of point in this. Broken authentication is the point i am really concerned now because I am about to install SSL certification on my website but also came to know about SSL Vulnerabilities that could happen even if you install it. So its better to take some knowledge yourself and as you mentioned Session hijacking might be possible in result, I figured out everything about it from one reliable source that mentioned everything about it in its Ethical Hacking tutorial. http://gotowebsecurity.com/ethical-hacking-course-session-hijacking-theory/. If sould know some countermeasures I think.

aftyer wasting my time and money looking for a hacker to hire on the clearnet, i finally found one on the deep web (no real hacker is on the clearnet). i am glad to share his email today. his email is hacktillinfinity(@)gmail(dot)com, he is the only one out there who will actually get the job done for you. the rest of them aren't really so good . thank me later and share with your friends so they do not waste money on fakes

For all Hacking and Private Investigation Service such as;
-Facebook, Whatsapp, Snapchat, any Social Media or Chat; Messenger
-Knowing if your Partner (husband, wife, boyfriend, or girlfriend) is cheating
-Change of Grades; Examination Hack; Hacking of University Portal
-Background Checks
-Email Hacking
CONTACT: [email protected]

Lukas Cerny

Not bad. Similar article I like https://www.veracode.com/blog/2015/09/10-common-security-vulnerabilities-and-markets-they-impact-sw
And the most common Wways to breach data security: https://www.ekransystem.com/en/blog/several-most-common-ways-breach-data-security

Ahmad Shakir

Hi Gergely,
Thats a nice post i think. Learned a lot things. But it would be better if you mentioned ways/ tools for identifying those security holes/ vulnerabilities as a security expert. Please suggest tools/ ways for identifying those security holes.
Thanks in advance.

AbdelRahman Mohammed

so let's find if Disqus is smart
<script type="text/javascript"> alert('gotcha'); </script>
that was a joke.. of course i didn't expect Disqus to be broken

Penny L Adams

Great post Gergely. Very helpful for newbies in programming. I agree that sensitive data exposure is one of the common vulnerabilities that newbies make. Here at my company, I conduct presentations and sessions for junior programmers. We give more importance to data security. The senior programmers will conduct the weekly sessions and monthly sessions will conduct by security firms like http://nci.ca in Mississauga. Anyway thanks for sharing this.

Chintan pathak

Good Article to start with website security

asdf

highest mistake: fall by ping -f

Faozul Azim

Concise and well....

Rodrigo Alves

Awesome article. Thanks

Richard Cochrane

Thanks Gergely. Great article and well explained. I totally agree about frameworks - I worked with a guy who used Django but then proceeded to write his own auth module. He was unwilling to see that his salt algorithm was flawed since he had designed it himself (and was not a security expert) and defended his SHA1 hashing, even though if he'd stuck with Django's auth module, it would've upgraded the password hashing to bcrypt for free (and it's been there for a while). Interestingly, I wrote my own security article for my company the day before yours and published it the day after. You make find it interesting :-) http://blog.mpowered.co.za/2014/05/30/cyber-security-good-fences-make-good-neighbours/

Joel Wallis Jucá

So, again, the security question depends on the technology usage. So if you are a good programmer who cares about security you'll write secure code. If you are a bad programmer, you'll write insecure code with whichever language you pick.

Enrique Conci

Hey Gergely, Excelent Post man!
You know, about relying in frameworks.... As a very conservative person I prefer to add modsecurity at the top and drive an exhaustive test over it, just to bring some peace to my mind. It's a tedious work to catch all those false positives but once you have everything in place you can sleep with both eyes closed and, the next morning see in logs "bad-robots", massive downloaders or crap like that dying against the software firewall. Again, this is my personal super-paranoic ultra-funky opinion :D
Thanks for posting this !!!

Gergely Kalman

Well, you are right, authentication and authorization must always be there and working. These will make this problem go away, or lessen it at least. But even then, there also remains the abstractioning problem where private implementational details are exposed and relied upon which is rarely a good idea.

Gergely Kalman

All of this is true, but a given technology/framework/company has a culture and culture has a lot to do with best practices and as such, security. OpenBSD is a very good example to good security, PHP stuff in general is one of the not so good examples. Not because PHP is inherently bad, or because PHP coders are not smart. It is because a lot of people who start programming go with PHP and produce lots and lots of very visible code that is vulnerable.

Craig Fox

Common Mistake #4: Insecure Direct Object References
The whole point of REST is to define Direct Object references. So, can you suggest best practices for accommodating this design pattern and still be secure. I would think that global authentication and appropriate authorization would be the solution.

Joel Wallis Jucá

Hehehe I was kidding.
Web security is all about the correct usage of the involved technologies. Web security requires a bit of paranoia to keep the software secure, with many required technical steps. So, there's no relation with technology A or B, your software stack and development practices will make your software secure or not.
To prevent some of those vulnerabilities I would advise the usage of open source frameworks, or even micro-frameworks for specific situations (ex: HTTP request handling, ACL, database abstraction and data security), so you will take advantage of contributed expertise on solving these kind of issues.
Congrats for the post! It's going to Twitter! :-)

Gergely Kalman

Not quite, PHP is used extensively as an example for a reason.

Joel Wallis Jucá

Well, taking a fast lookup in the post image I can guess that 10 most common web security vulnerabilities comes from the use of ASP/ASP.NET technologies. :-P