Presented ByNaveen Kumar Malla

Agenda

Web Application Security Threat Overview.Common Attacks & Preventative Techniques.How Joomla handles each attack.Writing secure web applications

Web Application Security Threat OverviewOften a web application is the only thing

standing in the way of an attacker and sensitive business information

Web application attacks account for 2/3s of all attacks

Firewalls only stop network service attacksDepending on the application an attacker

may be able to:– View or manipulate sensitive information– Obtain unauthorized access to an application– Be able to take control of the whole

application

Common Attacks & Preventative Techniques

Some of the common attack methods / strategies.

– Cross Site Request Forgery (CSRF)– Cross Site Scripting (XSS)– SQL Injections– Avoid direct access to folders/code– Register Globals

CSRFA Cross Site Request Forgery (CSRF) attack relies on the

trust a website has for a user to execute unauthorized requests and or transactions.

For Example:For example, one user, Chandu, might be browsing a chat forum where another user, Dhaval, has posted a message. Suppose that Dhaval has crafted an HTML image element that references a script on Bob's bank's website (rather than an image file), e.g.,

<img src="http://bank.example/withdraw?account=chandu&amount=1000000&for=dhaval">

If Chandu's bank keeps his authentication information in a cookie, and if the cookie hasn't expired, then the attempt by Chandu's browser to load the image will submit the withdrawal form with his cookie, thus authorizing a transaction without Chandu's approval.

How Joomla handles CSRF?POST Request: POST requests are submitted in HTML using forms. In order to

add the token to your form, add the following line inside your form:

<?php echo JHTML::_( 'form.token' ); ?>This will output something like the following:

<input type="hidden" name="1234567890abcdef1234567890abcdef" value="1" />

Checking the Token: Once you have included the token in your form or in your query

string, you must check the token before your script carries out the request. This is done with the following line:

JRequest::checkToken() or die( 'Invalid Token' ); If the request is coming from the query string, you must specify

this. The code then becomes: JRequest::checkToken( 'get' ) or die( 'Invalid Token' );

XSSCross Site Scripting (XSS) means executing script code

(e.g. JavaScript) in a visitors browser.

Conclusion:Use mosGetParam() for retrieving user input from a

request, it does strip out a pretty good amount of insecure stuff. But don't rely on it, also take a good look at places where you echo out things to the webbrowser. Apply

$value = htmlspecialchars( $value ); to strings before you echo them out to the browser.

Note:Be carefull not to echo out any unvalidated input to a user.

Code like this is dangerous for your visitors: echo $_REQUEST['value'];

SQL InjectionsSQL injections make it possible for attackers to modify

certain unsafe SQL queries, your script executes, in such a way that it could alter data in your database or give out sensible data to the attacker. That is because of unvalidated user input.

For Example:$value = $_GET['value'];

$database->setQuery( "SELECT * FROM #__mytable WHERE id = $value" );

An attacker could hand over a string like '1 OR 1', the query results in

"SELECT * FROM #__mytable WHERE id = 1 OR 1" , thus returning all rows from jos_mytable. I'm not going

more into detail here, as SQL injections are covered quite good on the web. Please take a look at the resources listed at the bottom of this post.

To prevent SQL injections Force the type you want

$sql = 'UPDATE #__mytable SET `id` = ' . (int) $int;

ALWAYS escape your strings$sql = 'UPDATE #__mytable SET `string` = ' . $db->quote( $db->getEscaped( $string ), false );

Prevent DOS attacks you can have a DOS vulnerability by not escaping the special

wildcard characters % and _.  Joomla has a facility to do this for you!  $db->getEscaped can take a second parameter which will escape those characters for you.  NOTE:  You only should escape these for strings used in a LIKE comparison.  So:

$sql = 'UPDATE #__mytable SET .... WHERE `string` LIKE '. $db->quote( $db->getEscaped( $string, true ), false );

Preventing XSS Attacks

Direct access to folders/code Instead of calling your component by http:/ /www.example.com/index.php?

option=com_yourcomponent , crackers also might try to use// // http:/

/www.example.com/components/com_yourcomponent/yourcomponent.php

As you can see, the PHP file will be executed directly, without Joomla! as a wrapper around it. Now, if your file only contains some classes or functions, but does not execute any code, there is nothing wrong about that:

<?php class myClass { [SomeFunctionsHere] }

function myFunction() {[SomeCodeHere] } ?>

Conclusion: To make your component secure against direct access, insert this

code line into the beginning of every PHP file that executes code: // no direct access defined( '_VALID_MOS' ) or die( 'Restricted

access' ); // no direct access defined('_JEXEC') or die('Restricted access');

Register Globals When this directive is On, PHP will inject extra variables in the

script such as HTML request variables, etc. The problem with this approach is that a developer cannot rely anything outside of his script and by injecting these variables an outside attacker could overwrite already defined variables or create potentially dangerous ones.

For example:PHP could inject these sort of variables in a script $username = 'hacked_username';Now if a $username variable was already set this would overwrite it. if ($authorized) { //show members only page } An attacker could alter the value of this variable simply by using

GET auth.php?authorized=1 if the above code snippet is found in auth.php file

The best practice, that every developer should follow, is setting register_globals directive to Off and use the already defined PHP superglobals such as $_GET, $_POST.

Writing Secure Web applicationsSanitize browser inputDon't put everything in the HTML directoryAvoid the shell 'hidden' fields aren't Use POST instead of GET Validate on the server Avoid real directory and file names Use absolute path and filenames Specify the open mode when opening a fileLog suspicious errors

Referenceshttp://docs.joomla.orghttp://advosys.ca/papers/web/61-web-security

.htmlhttp://fscked.org/blog/fully-automated-active-

https-cookie-hijackinghttp://blogs.securiteam.com/index.php/archiv

es/1268

Any Queries?

Thank You