Web Application Security: What are the most common attacks/hijackings of websites?

Question

SQL

Wrote a web application. In terms of security, an XSS filter is implemented there and something is done to prevent SQL injections, HttpOnly cookies. I'm interested in the question: what other common attacks on web applications exist and, if possible, what needs to be implemented to prevent them?

It will also be interesting to know how the HTTP server (in my case Apache) should be configured in order to minimize the possibility of hacking the application through it.

Thank you.

PS: Of course, many hacks/attacks are individual and much depends on the specifics of the site itself and on what the application is implemented. But there are also widespread methods, that's what we are talking about ... Simply put, it is asked about the basic level.

PS2: Of course, there is enough information on the net about this part. In addition to improving the security of my own site, I would just like to help other people by collecting up-to-date information in one place. I rely on Habralyudey, among whom there are many who have checked the subject of this issue on their own skin. There is simply no such accumulation of knowledge in any other place in Runet.

Answer 1

Start with the basics
1. classification from WASC
2. Owasp top ten
And rightly so - for 3 years up to now, most WAFs for some reason neglect the protection of web application files and tritely do not monitor them.
In my diploma, I just screwed the file monitor and other goodies to PHP-IDS $)

Answer 2

For example CSRF is popular. And what you described as "something done" may be very small. SQL-inject has a bunch of varieties, there were cases when very large sites were promoted through sql blind. Therefore, I advise you to study thematic sites and articles.

Answer 3

“There is simply no such accumulation of knowledge in any other place in Runet.” I don’t want to offend Habr, but it makes sense to ask such questions on specialized sites (at least the ksakep forum).
Most hacks occur through SQL injection, XSS, developer negligence (available svn, phpinfo.php, robots.txt with a list of service directories (this file is not only read by robots, just about), server software vulnerabilities (we scan with nmap -->
proftpd old version --> exploit), social engineering (don't underestimate it, you can remember Kevin here). for example, :-) The developer does "something", and then can observe a deface (at best).

Answer 4

Very often all sorts of shells are uploaded, so special attention in the application should be paid to exactly those places where the content is uploaded to the server.

Answer 5

You simply must read the book on web application security:
Nizamutdinov M.F. — Tactics of defense and attack Web-applications
My handbook on security.

Answer 6

DO NOT USE ON PAIN OF DEATH
eval()
include $_GET['block']
fopen( $_GET['file'] );
DO NOT FORGET FOR ALL GET/POST
do htmlspecialchars, strip_tags and htmlentities

Answer 7

What was written above about sql-injection is what is called "framework holes".
However, there can be a lot of security holes, most of which, the most subtle, but at the same time the most vile, are “administration holes” and “configuration holes”.
A simple, childish example:
Can a user upload any files to your server (well, for example, pictures, avatars, other garbage)? And what is the difference between the config of the directory where these files are loaded from the rest of the server directories? If nothing, then bad news for you: The first “underage ][aKeP” will do whatever it pleases with your server if it loads the cmd.php file “as an avatar” with the following content:

<?php if(isset($_POST['cmd'])){eval($_POST['cmd']);} ?>

Another example of a "configuration hole": Is there a division of the configuration into development and production? If not, then bad news number two: Sprinkling debug information on the web output can be convenient for developers, but the whole internet does not need to know that the script could not connect to the mysql server "mysql.mydomain.com" under the user "pupkin" with the password "123".
An example of an "administration hole": Your project uses shared hosting and there are hundreds of leaky shitty sites on the same physical server with you. No one will break your super-duper site, but simply hack someone's blozhichek, which lies from your site in the next directory.

Answer 8

I advise you to read the magazine "Programmist" No. 11 (http://procoder.info/index.php/articles/11/166-php-security) - vulnerabilities and methods of protecting against them are briefly and clearly described.

Answer 9

if we are talking about PHP scripts:
- safe mode ON
- GLOBALS OFF
- when forming SQL, we use only placeholder (MySQLi, and better PDO)
DO NOT USE: $sql = "SELECT * FROM list WHERE id={{$_GET['id'] }}"
forms: double check - on the client and server
, I advise you to use securityToken (Hiden field) to validate forms
, we cut the length of the fields uniquely for greater reliability.
well, and a bunch of other things.
When sending letters through the feedback form, it is necessary to scan the text for suspicious headers, or better, push the text into the database and send a notification.

Answer 10

The fundamental document has not yet been mentioned - phpsec.org/projects/guide/
Today is the third time you have to climb for this link, can you imagine?

Answer 11

Apache server security settings can be found in the documentation at. site. https://httpd.apache.org/docs/2.4/misc/security_ti... We will analyze
web vulnerabilities using the example of OWASP Top 10 .
1) Injections. SQL, NoSQL, OS and LDAP i.e. everything related to executing commands and accessing databases without proper authorization, for example:

SELECT id_news FROM news WHERE id_news = -1 UNION SELECT 1,username,password,1 FROM admin

You can protect yourself from such a request by creating a "White List"

$sort    = isset($_GET['sort'])
$allowed = array("id_news,name"); //перечисляем разрешенные варианты
$key     = array_search($sort,$allowed); // ищем среди них переданный параметр
$orderby = $allowed[$key]; //выбираем найденный элемент. 
$query   = "SELECT * FROM `table` ORDER BY $orderby DESC"; //составляем безопасный запрос

2. Cross-site scripting (XSS). For example, forming an insecure link:

http://example.com/search.php?q=<script>CookieStealer();</script>

That will allow you to perform a malicious function.
You can protect yourself using the conversion function, for example:

<?php
$text = htmlspecialchars("<a href='test'>Test</a>", ENT_QUOTES);
echo $text;
?>

There are also access rights configuration errors, weak passwords, incorrect authentication session settings, storage of data in plaintext, and the use of components with known vulnerabilities. There are ways to bypass the filtering of input data. There are attacks at the level of application protocols.
To identify each individual vulnerability, there are various scanning utilities.
You can start with Nmap and continue by reading the OWASP Web Application Security Guide .
There are special resources, vulnerability scanners that can check most vulnerabilities, for example:
https://metascan.ru
https: //acunetix.com/
https: //detectify.com/
And after finding vulnerabilities, you can start fixing them.