Invasion forms, ideas on how to hack a website

Invading a website today, with so many programming languages and disqualified professionals selected by the selection processes, where they are well evaluated in psychological matters but very poor professionals in terms of experience, receiving low salaries, and, unmotivated, the fragility of any website, system, can be a measured item.

Another important item to be highlighted, is that large projects, there must be a flow, a control by someone specialized, who at least has worked with programming, and who knows the invasion tactics, some presented here, free of charge.

Read on for more details on these ideas, and how to immediately shield your site from attacks by all kinds of people today.

1. Superficial attack

Superficial attacks, or which only affect the front-end, are diverse, and these attacks can gauge the behavior of the page, bringing content from other places on the internet, changing the behavior of the current page. This is also known as an XSS attack, or better known as Cross Site Scripting.

We will search the site for some comment fields, and we will make some comments like:

Hello guys, how are you?<script type="text/javascript">alert("Hello, welcome to the site!");</script>

If after you comment, you enter the site and see a "Hello, welcome to the site!" Pop-up, you have just "hacked" the site. However, this attack is only superficial, it does not reach any file on the server, nor data, nor any other type of action can be performed, since generally the content of text fields, are saved in the database, and will only be reproduced in HTML format when displayed again.

It turns out that if you have HTML code being interpreted, it may well be rewritten, and re-executed by a third party, without the site owner's authorization.

This allows you to inject a script from anywhere else on the internet, and have a "remote control" of the attacked site at any time you want, changing the behavior, changing the page, as JavaScript allows you to perform any action on the front end of the page on the client .

Many Brazilian government websites are made this way.

2. CORS, what is this? "Hacking" a website with iframe.

Have you ever thought about your site being opened by another domain that you don't own and being indexed on Google with greater relevance than your own site? As well? I'm going to explain to you.

You have a website, XPTO.com.br (this is an example), but someone put your complete website, likewise, in an iframe for XPTOX.com.br, however, this domain is not yours, it belongs to a third party .

Using tactics to increase the Pagerank of the site on Google (by disclosing the fake URL more than the original), the third site starts to have a larger user input than the original domain, as it will appear above in the search results.

Now you have already thought about your website on a third-party domain, what can it do overnight? Should you put something defaming your company? Create a website saying "You have been hacked", what is the image of customers for your company? Good isn't it, right?

Worse, if this XPTOX.com.br site is filling up with clicks on the site using scripts that run on the parent page (XPTO.com.br is giving away an iframe), they can make your server work much more than usual .

For this there is CORS, which is a tactic to prevent any other site from placing your site as an iframe, so your site will only run on your root domain.

Just put the HTTP header:

Access-Control-Allow-Origin: http://xpto.com.br, http://www.xpto.com.br

And, no one else will be able to place your site as an iframe, anywhere else, at least not in new browsers, as they will reject any iframe that has this configuration enabled, and the source domain is not specified in this header.

3. Denial of service attack on SQL query

Let's look on the site for something that takes a few seconds to process, such as in the news area, if there are any filters for the user to select, or in the product catalog of the virtual store.

The ideal is to look for a filter that makes the site take longer to respond, at least, more than 2 seconds thinking without even starting to bring data.

This means, that the site takes considerably reasonable time to bring information from the database.

But now, let's assume the following equation:

If only 1 access takes 2 seconds, then 10 accesses would take 20 seconds to process. Not exactly. Databases usually work with caching in the last queries, but still, it will take at least some time, let's assume that even with caching, 10 hits takes 10 seconds, that is, 1 second of processing per access.

If this same person makes simple software, which pulsates the URL in 1 second with filters, changing some parameters per query, to avoid caching, we may have a good unavailability of the site in the processing of real queries.

There is also, something that can happen (and a lot), and that can make any application unstable, is when there is a query being executed, and in the website programming, there is some sub-query being executed within the main query, where the programmer does not optimized the main query to obtain sub-query results within the query itself.

In these cases, pagination of catalogs, where they bring various products, and prices, details, are usually in another table, or images, especially if there are several images (ratio 1 to N), then there is no other way than to perform this sub-query.

If you can find a filter that instead of bringing 10 products per page, you can bring 1000 products or 10,000 products, this can also bring down the site, especially if the subquery is being produced only by the server-side (html comes ready in view- source), instead of jquery, which can have lazy load and load only what is in the viewport (but, generally, nobody does this, as it is much more work).

This URL that asks for the 10,000 products, can take 1 to 2 minutes to be processed depending on the server, and the longer it takes, the easier it will be to bring down the server (via the database).

If each access takes 1 minute, and if it pulsates every 1 second, the server will start to operate more and more slowly, as it will not have enough skill to be able to meet the demand of the running queue, and IIS or Apache, can queue the order processing queue in the process pool, until the process is closed due to failures, and the site is actually brought down.

If there is no log enabled, or monitoring on this server, monitoring routines in the processes, the site may take hours to be reestablished, although the action of resuming is just a simple restart in the process, however, the main cause was a wrong elaboration of a query.

4. SQL Injection

Try to use codes in form fields:

' or 1=1 or 1 = '
' or 1=1--
' or 65445=65445 or 'a' = '
' or true --

If the site behaves strangely, it may be vulnerable to SQL Injection attacks, and its entire database may be compromised.

Remember, the digit "-" is almost always forgotten by programmers, as they are generally unaware of its existence, but this means that everything afterwards is commented, just like "//" in JavaScript.

This is because in SQL Server, the way of commenting is by default, like this:

/ * comment * /

But no one imagines that there is also a comment for just one line:

SELECT * FROM PRODUCTS WHERE NAME LIKE '% Amora%' - PRODUCT

And this is valid to be executed, as if it were "//" in PHP or JavaScript.

5. Server Side injection

The action here is to try to upload a file via upload, either in comments, or anywhere else, and have the script run on the server.

This script can be in ASP or PHP, and there is just no protection to upload files with extensions of this type.

Generally, upload files in "Work with Us", or in other areas of the site, have the file name renamed to another name, to avoid duplicates, and also, who uploaded it, does not know which URL to call the file.

For this reason, within this file, it must contain a programming code to trigger e-mail as soon as it is executed, giving the URL where it is being executed. Therefore, it is even possible to generate a false resume for the user of this system, which when trying to "read the resume", in reality will start to execute the PHP script, and then, it will pass the information to the attacker by email, and , will issue a fake resume.

With the script running, and functional, and the known URL, many other things can be done. If the injected file is a "web file manager" type, you will have access to all files, write, read all data, passwords, etc.

That is why it is important that the site avoids uploading files as much as possible, and, if you do, do not save to the same Web server, but save to a separate server, such as an Amazon S3, where no code is executed, only served static files.

If you need to save these files on the server, at least make sure that the folder has its permissions properly configured to not allow the execution of files, and only work with static files.

Completion

These were some ideas based on some types of attacks that can happen and that, in short, are easy to avoid, but that programmers do not always take into account when making adjustments or developing systems.