The document discusses common web application security threats like cross-site request forgery (CSRF), cross-site scripting (XSS), and SQL injections. It provides examples of each threat and explains how Joomla handles them, such as by adding tokens for CSRF protection and escaping user input. The document also covers other attacks like direct code access, register globals being on, and outlines best practices for secure web development like input sanitization and validation.

1. Presented By Naveen Kumar Malla

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

3. Web Application Security Threat Overview Often 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 attacks Depending 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

4. 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

5. CSRF A 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=&quot;http://bank.example/withdraw?account=chandu&amount=1000000&for=dhaval&quot;> 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.

6. 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=&quot;hidden&quot; name=&quot;1234567890abcdef1234567890abcdef&quot; value=&quot;1&quot; /> 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' );

7. XSS Cross 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'];

8. SQL Injections SQL 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( &quot;SELECT * FROM #__mytable WHERE id = $value&quot; ); An attacker could hand over a string like '1 OR 1', the query results in &quot;SELECT * FROM #__mytable WHERE id = 1 OR 1&quot; , 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.

9. 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

10. 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');

11. 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 .

12. Writing Secure Web applications Sanitize browser input Don't put everything in the HTML directory Avoid 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 file Log suspicious errors

13. References http://docs.joomla.org http://advosys.ca/papers/web/61-web-security.html http://fscked.org/blog/fully-automated-active-https-cookie-hijacking http://blogs.securiteam.com/index.php/archives/1268

14. Any Queries?

15. Thank You