Vulnerabilities in web applications and their prevention

VULNERABILITIES IN WEB APPLICATIONS AND THEIR PREVENTION

Serhii Hamotskyi

NTUU “KPI”

 

In today’s high technology environment, organizations are becoming more and more dependent on their information systems. In the past few years, the public is becoming aware about the importance of the proper use of its data, and the threats to information system and particularly websites are increasing. Much of the value of a business concentrated in the value of its information, and protecting it is crucial. Data leaks can affect a company very seriously

Protecting a website is always cheaper than dealing with a breach or data leak.

A language can’t be insecure by itself, but PHP offers a lot of opportunities to shoot yourself in the foot. In Ukraine, the problem is that a lot of people learn PHP by themselves and start writing websites which appear to work, but they have no idea about how they can be exploited.

We will focus mostly on LFI/RFI, due to time limits, but I think that it will be enough to get the point about how easy it might be to breach a poorly-written website, despite the fact that it looks okay if you don’t know what to look for, and the need to research further this topic if it is relevant to what you do.

Now, in more details, about LFI/RFI: any page which dynamically includes content from other places without proper validation is potentially vulnerable. LFI can be used in a lot of ways, from reading files (config files, password files, PHP scripts source code) to executing code on the server (via a technique called Log Poisoning which I won’t cover here). RFI – Remote file inclusion – can happen with the same code; the only difference is that remote files can be included too (depending on the configuration of the webserver and OS). It’s often used to include .txt files with code in them, which is executed. Often they contain a shell – a tool written especially to make further penetration easier.

Protecting from LFI/RFI might include the following:

1)               Don’t include files dynamically.

2)               If that’s not possible, check whether they are one of the previously selected possible values.

3)               Or check for symbols which shouldn’t be there, and either return an error or try to remove them. If you choose to remove them — do it until there are suspicious symbols

Except protecting from specific vulnerabilities, there a few good practices which can make your application harder to hack.

All data received from the user should be considered dangerous until proven otherwise. Cookies and hidden fields included. (If you set a cookie and read it later, there’s no guarantee it’s the same one.)

Some attacks abuse the application’s trust to requests which appear initiated by itself, XSRF or Clickjacking, for example.

The system should be protected from all sides, not just web attacks. There’s no point in having a metal lock on a glass door (or, without metaphors: a fully secured website won’t protect a corporation’s data if the offices aren’t locked: somebody can just enter with a USB drive, turn any computer on, boot from the USB to bypass any eventual passwords, copy the confidential data and leave. This is part of a discipline sometimes called “No tech hacking”, which is as dangerous as the more talked about classic hacking).

Know what Google has indexed on the website. Even if the content has never been explicitly linked, Google has been known to scan emails for URIs and add them to their search results.

Design a good authentication system – usually it’s going to be attacked first and it’s the hardest to implement well.

Don’t use an easily guessable URI for the admin panel; Don’t list it in robots.txt

Never save the passwords in plain text, they should be hashed, using multiple algorithms and salt. That way they’ll be harder to crack if a breach happens.

Don’t use trivial passwords and default accounts; Passwords shouldn’t be reused.

To conclude, information security is a fascinating topic and writing a secure web application is not as easy as it seems at first sight. We just looked at how seemingly correct code can be exploited – for the other vulnerabilities it’s not much harder. An understanding of how security can be broken is crucial to write a secure website.

 

References:

1. Hackers stole $2.7 million from Citi| Reuters. (n.d.). Retrieved from http://www.reuters.com/article/2011/06/28/us-citigroup-idUSTRE75R7G220110628

2. Mitnick, K. D., & Simon, W. L. (2005). The art of intrusion: The real stories behind the exploits of hackers, intruders, & deceivers. Indianapolis, IN: Wiley.

3. Mitnick, K. D., & Simon, W. L. (2002). The art of deception: Controlling the human element of security. Indianapolis, Ind: Wiley Pub.

4. Top 10 2013-Top 10 — OWASP. (n.d.). Retrieved November 19, 2013, from https://www.owasp.org/index.php/Top_10_2013-Top_10

 

PowerPoint Presentation - click to download

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>