I have seen many people say that their website has been hacked using some vulnerability. I never fully understood what this means.

To me the only way to get control of website is get the FTP details.

So, I presume hacking means that some other person got the FTP details somehow. Is this correct?


This is a very broad question. The word "hacked" is not very descriptive; a technical person is more likely to describe specifically what happened. Usually "my site has been hacked" is used to mean "My website/webserver is doing something bad/unwanted/surprising."

Here are some ways this can happen:

  1. The attacker gains access to the web server (the operating system or web server application itself). This can be by guessing or stealing the various credentials used by the server administrators (FTP, SSH, SQL, etc etc.)

  2. The attacker manipulates the existing web page to make it do something unintended. This could be via methods like SQL Injection or Cross-site Scripting vulnerabilities. See a more detailed list at the Open Web Application Security Project (OWASP)

  3. The web server is behaving normally, but the user(s) or administrators don't understand what it is doing, and think it has been "hacked". In 2006, CentOS was threatened with "an official complaint to the FBI" by a city manager who mistook an Apache Web Server configuration page for a successful hack.

Please clarify or ask further questions if there is anything you don't understand. It's a very broad topic!


The term "hacked" can have several different meanings when related to attacks on a web site. Let's focus on the different targets of the several kind of "hacks":

  • the service provided - some attacks (DoS / DDoS) aim at making a specific service unavailable to its users, possibly resulting in loss of revenue
  • the information stored - attacks (e.g. SQL Injection) rely on vulnerabilities to disclose sensitive and critical information stored on the database or on the server itself
  • the server itself (web / application server) - an attack could result in the compromise of the underlying server (e.g. disclosure of SSH/FTP credentials)
  • users - attacks can (ab)use a vulnerability on the web site to harm its users (e.g. Cross-Site Scripting, Cross-Site Request Forgery, Open Redirect)
  • other domains - vulnerabilities can be abused to attack different web sites, hosted on different domains
  • Of all these answers, I like this one the best. It provides very concise, accurate layman descriptions of the various different meanings. Not overly technical, but enough to give ideas for follow-up questions if necessary. Jan 4 '13 at 17:01

This is a very broad question, but I'll do my best to cover it all briefly.

A website can be a very complex piece of software. Whilst many sites may be static, i.e. only serving plain HTML documents, a large number of them are dynamic, i.e. outputting HTML content from a script, which may access database resources or files. These are commonly written in PHP or ASP.NET, but there are many other technologies out there. As such, an error in one of those scripts might allow an attacker to compromise the server.

However, we're already getting ahead of ourselves. The server is already an extremely complicated system - it contains hardware, firmware and software. The hardware takes signals from external sources (e.g. a network cable, or a keyboard) and translates them into data that can be stored in RAM and processed by system software. The translation process and state management is often handled by a special type of software running directly on hardware peripherals, which is called firmware. That firmware helps translate the incoming raw data into the complex structures needed by the system software. From there, the operating system software (e.g. kernel) takes those raw structures and provides a layer of abstraction to user programs. This can be another very complicated set of software. On top of all of that, we have user programs that run on the operating system, which might include your web server or FTP server.

All of these layers represent an attack surface, which essentially means that they have a potential for software bugs that might be exploited by an attacker. The most commonly attacked layer is the user programs, but all of them have potential as a target. For example, the firmware of a network card might decode the 802.11n wifi protocol, then translate the data into ethernet frames. If a flaw is discovered in the network card's firmware, it may be possible to cause the device to malfunction, by sending a specially crafted packet of data over a wifi signal. This might result in a denial of service (DoS) condition, which causes the device to stop transmitting and receiving data.

The operating system is an incredibly complicated piece of software, which again may represent a large attack surface. Vulnerabilities in the operating system and its kernel are less common these days, but they still exist. A good example of this is MS08-067, which is a vulnerability in a Windows service that allows a remote attacker to send a specially crafted packet that contains executable code, and that code ends up being run on the server. That code might cause a new user to be created on the system (which can later be logged into via remote desktop) or a command prompt to be spawned and piped back to the attacker over a TCP connection. Both of these types of attack result in the attacker fully compromising the server, without ever needing to know credentials for the server itself or its FTP service.

Of course, these types of bugs also affect user-installed services, including the web server software itself (e.g. Apache / IIS) and FTP, SSH, VNC, SQL, etc. It's entirely possible for any of these services to have remote code execution bugs, command injection bugs, denial of service bugs, authentication bypass bugs, etc. Keeping them up to date is critical, because these bugs are frequently discovered and patched. Not keeping them up to date might result in an attacker using a bug to gain unauthorized access to the system.

Finally, we have the actual website. If you're using a dynamic site (known as a web application) via PHP or ASP.NET, you're essentially taking a HTTP request from a user, parsing that HTTP request into a format that can be understood by the web application, performing an action based on the request, and outputting some content. All of these areas might have bugs in them, but the most common area is the part where an action is performed based on the user request. For example, we might take a parameter from the URL and use it in an SQL database query to get a list of forum posts, then output the results in a HTML format. If the SQL query operation is poorly written, a malicious user may be able to craft a specially formatted URL that causes the query to behave differently - for example return all user records rather than all forum posts. This is called SQL injection. They can then take those credentials and crack any hashed passwords offline, then use them to log into the site.

Another common vulnerability is an Insecure Direct Object Reference bug, which occurs when a web application doesn't properly control access to resources. For example, you might have a list of documents that your user has access to, with numeric IDs being passed into a script which displays the document, e.g. document.php?id=123. Whilst the list of documents only displays the ones the user has access to, the user might change the ID in the URL to directly reference a document that they shouldn't have access to. If proper checks aren't included, the user might be able to access pages or operations that they shouldn't be able to. This might result in a malicious user being able to change another user's settings.

Two other common vulnerabilities, Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF), allow an attacker to send a legitimate user a specially crafted link to a vulnerable site, which ends up executing some JavaScript or performing an operation on the site which the user did not expect. This might result in the theft of their account or personal information. From these harvested pieces of information, the attacker might be able to log in as that user, or perform other operations that they shouldn't be able to.

Many other classes of web application bugs exist - remote file inclusion (RFI), local file inclusion (LFI), unrestricted upload bugs, session ID leakage / predictability, insecure communication, etc. It's probably a good idea to check out the OWASP Top 10 for a more comprehensive list.

So, all in all, there are a lot of vectors via which an attacker may break into a website, and services such as FTP are only a small part of the picture.


No, there are many, many other ways that a site can become compromised. FTP is just one of many ways to get data onto a site. Other protocols such as webdav or even HTTP can be used to transfer files to a site. Additionally, most websites have a database back end that stores persistent information about the contents of a site. Almost every blog, news site, forum, store and search engine you've ever visited has a database.

The database is by far the more common attack vector than getting actual access to the files. Techniques like SQL injection can allow malicious commands to be sent to the database as if they were legitimate commands. This can lead to either information (like passwords or password hashes) being leaked or can result in information being added, such as a hacked message on the front page of the site.

Other techniques attack the site without having to attack the server itself. A category of attacks called cross site scripting work by looking at ways that they can submit information to a site in such a way that it will do malicious things on an end user's computer under the permissions or session of their connection to a legitimate site that they trust. This is typically a Javascript attack, though other vectors can be used.

More rarely, an exploit can exist in the actual software that runs the server a site runs on and those exploits can be used to gain access to do things the site or server shouldn't normally do.

All in all, referring to a site being hacked simply means that someone did something that compromised the integrity of the site, and that could be any number of different things, of which getting the FTP password is probably just about the least common (though it does still happen).


When your website gets hacked it means, there is unauthorized access or modification to the website

Your server may be running HTTP and FTP services so it is possible that someone has found the credentials of the FTP. Sometimes vulnerabilities are discovered to circumvent any username and password!

Perhaps the FTP service doesn't have any vulnerabilities that allow you to bypass the username and password, but perhaps it has a vulnerability that starts another service or install another program such as SSH or RDP! Then the new service or program can be analysis for vulnerabilities.


"So, I presume hacking means that some other person got the FTP details somehow. Is this correct?"

That is incorrect.

There are many different ways a website can be hacked. SQL injection comes to mind right off the bat.

When someone says that their website has been hacked, they mean it has been compromised - meaning a person or system has gained access to data that they otherwise should not have been able to access.


That is incorrect.

A hacker can exploit some vulnerabilities like SQL Injection, XSS, LFI, RFI, authentication bypass.

He could bruteforce the FTP login or get access via SSH.

Or maybe if you had a shared hosting, even if you don't have any vulnerability in your website, a hacker can exploit other websites on the same server and then he could use a Privilege Escalation exploit to hack the entire server and just upload or inject some codes to maintain access.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.