Take the 2-minute tour ×

I know websites are hacked because of loose ends but how are they hacked via a form? Is it because the website owners didn't validate the form and the way they structured?

share|improve this question



Mostly by pissing off a hacker. –  Aditya P Apr 27 '11 at 11:53
Possibly a better question for: security.stackexchange.com –  Orbling Apr 27 '11 at 12:01
It doesn't "become" hackable. It's built that way. Or configured that way. On purpose (usually through ignorance of better design alternatives.) –  S.Lott Apr 27 '11 at 12:56

6 Answers 6

Yes, there are several ways to hack a website through user input.

Luckily for you, the developer, there are security check lists that you can use to read up on security vulnerabilities such as the OWASP Top Ten. It changes every year but among the most common you'll find:

  1. Injection
  2. Cross-site scripting
  3. Really broken session management

... and so on. You can start from the main page for this year's top ten list. From each item in the list you'll get links to checklists and other resources such as the PHP Enterprise Security API.

share|improve this answer
OK so basically making sure you strip slashes, prevent words like script or ' or 1'='1 among others should searched for and taken out. How about in links, if i just strip slashes is it good? –  KPO Apr 27 '11 at 11:43
@KPO: That may help injection, and preventing words like script only annoys the user if he actually needs to write script (it is quite a common word). For the latter you should let the code escape html characters to html entities. –  Spoike Apr 27 '11 at 11:50
Also, on another note, a website doesn't have to be exclusively hacked through a form. It could be done through the query string in an http adress or insecure server settings (allowing file upload/download). –  Spoike Apr 27 '11 at 11:51
There is no simple "let's strip slashes and do X then Y" to avoid an attack upon a website. It's an holistic approach in designing your web application. For details about what you have to take into account take a look at the Open Web Application Security Project (owasp.org/index.php/Main_Page) –  perdian Apr 27 '11 at 11:52
@KPO: "so basically making sure you strip slashes..." No. It's not that simple. Please read owasp.org/index.php/Category:OWASP_Top_Ten_Project to get started understanding the issues. –  S.Lott Apr 27 '11 at 11:58

The tag php already gives a hint :P

But more seriously, there's a number of common mistakes:

  1. The sent data is not properly retrieved, for example all request variables are automatically imported (using register_globals).
  2. A variable sent is used to include a file, as in include($_REQUEST['action']). If allow_url_include is set, and $_REQUEST['action'] happens to be a url to some script, the interpreted will load it from there and execute it, which allows executing all kind of evil stuff. This doesn't even require allow_url_include. If you site allows uploading files, you can first upload the script and then include it.
  3. A variable sent is used in an SQL query without proper escaping. This allows SQL injection.
  4. A variable sent is displayed as content to other users, without html escaping or stripping out dangerous tags (such as script), which allow running arbitrary code on the clients.
  5. By allowing GET submissions of the form and using only cookies for session management, your site becomes vulnerable to CSRF.
  6. Exploiting bugs in the C implementations of various PHP functions (integer overflows, buffer under-runs etc.).

Basically any decent framework handles 1-3 for you out of the box, 5 can also be automated by simply requiring POST, or even better, adding some authentication token to the form. Also 6. is best dealt with by keeping your PHP version up to date, since the vulnerabilities are known and fixed. Of all things 4 is probably the trickiest one, if you want your users to be able to use a subset of HTML but it's not impossible.

share|improve this answer
5 cannot be solved by requiring POST. It's trivial to auto send a form via POST to a vulnerable CSRF website using javascript and an iframe. –  Carlos Campderrós Apr 27 '11 at 15:10
@Carlos: Care to share a link? –  back2dos Apr 27 '11 at 16:21
You can check the PHP Suhosin patch. –  Joset Apr 28 '11 at 3:39
@Carlos: Interesting, thanks. I thought same origin policies would forbid this. –  back2dos Apr 28 '11 at 12:01

The different ways that bad people do bad things to your applications are wide and varied. In some respects, no matter how paranoid you are it's probably not enough. So start with the basics first:

  • Make sure your server isn't running anything not critical to the application, and you know what all the configuration settings are doing.
  • Never trust anything a user gives you. Both injection attacks and cross site scripting attacks are given power because the app simply accepts and uses what they've been given. The input needs to be scrubbed, and when you display that information you have to make sure that only the formatting you want is preserved.
  • Make sure you handle errors properly. Stack traces reveal a bit about your server stack. If you are running C# code, there are things that the attacker can do to attack the OS or IIS because they know that's the server you are using. Java's not exempt either, the stack trace includes server information if you don't catch and handle it properly.

There's a lot more you should read up on, but in the interim just know it's not a simple problem. You should have multiple lines of defense, and don't just rely on the web application to handle everything about the security.

share|improve this answer
So technically its a whole host of things from server config to db config to form scripts. Thanks. got to learn smoe. –  KPO Apr 27 '11 at 12:07
@KPO: "whole host of things". Not quite. It's everything. Every aspect of application, configuration, deployment and operations. Including how much you trust the people that know the passwords. –  S.Lott Apr 27 '11 at 12:58

All are hackable. This is self-explanatory.

Some factors are:

  1. 0 day - some unknown threats are still emerging
  2. Social engineering - no matter how secure your site is, if the user doesn't care about security
  3. Hackable platform / operating system - no matter how secure your site is, if the underlying platform is insecure

e.g. Running LAMP stack i.e. with PHP + Suhosin patch on an insecure Linux box defeats Suhosin's purpose one way or the other

share|improve this answer
You make it sound like there is no need for security. –  JeffO Apr 27 '11 at 11:52
@Jeff O: There is a need for security. –  Joset Apr 27 '11 at 11:58
@AdityaGameProgrammer: Why do you say so? –  Joset Apr 27 '11 at 12:02
Most websites are hackable, if enough is known about them, or enough time is spent fathoming things out. –  Orbling Apr 27 '11 at 12:02
no Jeff, he's just saying that no amount of security will catch everything. –  jwenting Apr 27 '11 at 12:15

Websites become hackable when they are created/extended. Programmers often focus on certain functionality and dont think much about "side effects". Hackers (or should I say Crackers) on the other hand are very open minded and take completely different approach. They are interested in what web application can do, not what it was intented to do. So they take their time in testing various parts of website and when they somehow cause web application to misbehave, they know they hit a hot spot. All the hints that you can find on-line (validate inputs, escape queries) are naturally correct, but following them won't guarantee hack-free website. Some of the best hacks out there (eg. apache.org) were carried out after finding out a very small, at first meaningless fact about a web site, and then working from there.

share|improve this answer

Websites become hackable by someone discovering a security hole in what you thought was save. It's a constant learning curve for the offense and the defense. It's a war, with each side constantly escalating.

The best defense is to be undesirable. If your site handles money - eCommerce, banking, whatever - then the maintentnace cost is ten times what it would be without the money handling. Showcase sites can be patched once a month; e-commerce sites should be patched hourly.

No matter how secure your site code is, if the hosting service is incompetant then the infrastructure - Apache, MySQL, etc - will have unpatched holes in it. Nothing you can do about that except change the hosting service.

share|improve this answer
