For all too many companies, it’s not until after a 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:

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

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

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

 4. Session fixation might be possible.

5. 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.
Related: 9 Essential System Security Interview Questions

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:

1. Running the application with debug enabled in production.

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

information.

3. Running outdated software (think WordPress plugins, old

PhpMyAdmin).

4. Having unnecessary services running on the machine.

5. Not changing default keys and passwords. (Happens way more

frequently than you’d believe!)

6. 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.

Prevention:
 In transit: Use HTTPS with a proper certificate and PFS (Perfect Forward
Secrecy). Do not accept anything over non-HTTPS connections. Have the secure
flag on cookies.
 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:

http://example.com/app/transferFunds?
amount=1500&destinationAccount=4673243
243
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:

<img src=http://example.com/app/transferFunds?

amount=1500&destinationAccount=4673243243 width=0 height=0 />

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!

For more information and more specific server side attacks, have a look
at: https://www.owasp.org/index.php/Category:Attack.
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].
Here’s to website security! Cheers.