Your SlideShare is downloading. ×
0
Joomla security nuggets
Joomla security nuggets
Joomla security nuggets
Joomla security nuggets
Joomla security nuggets
Joomla security nuggets
Joomla security nuggets
Joomla security nuggets
Joomla security nuggets
Joomla security nuggets
Joomla security nuggets
Joomla security nuggets
Joomla security nuggets
Joomla security nuggets
Joomla security nuggets
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Joomla security nuggets

5,971

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
5,971
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Today most the business is running through web and even most of the attacks are also done through web hackers only.
  • Application Attacks vary and evolve rapidly to exploit newly created or identified vulnerabilities as do the reasons and consequences of attacks. Other Attacks: – Cookie Attacks – Database Interaction – Hidden Fields
  • The attack works by including a link or script in a page that accesses a site to which the user is known (or is supposed) to have been authenticated
  • Joomla! attempts to protect againt CSRF by inserting a random string called a token into each POST form and each GET query string that is able to modify something in the Joomla! system.
  • For Integers: $int = JRequest::getInt( $name, $default ); For Floats (decimals): $float = JRequest::getFloat( $name, $default ); For boolean values (true/false): $bool = JRequest::getBool( $name, $default ); For "words" (only allows alpha characters, and the _ character) $word = JRequest::getWord( $name, $default ); For "commands" (Allows alpha characters, numeric characters, . - and _ ) $cmd = JRequest::getCMD( $name, $default ); For NON-HTML text (all HTML will be stripped) $string = JRequest::getString( $name, $default );
  • Conclusion: Validate all user input before you use it in a SQL query. Apply $string = $database->getEscaped( $string ); $string = $db->getEscaped( $string ); to all strings that will be used in SQL queries, and apply $value = intval( $value ); $value = intval( $value ); to all integer numbers you use in SQL queries. Again, for more information on SQL injections, please take a look at the listed resources, especially .
  • The files of your component will usually be called by Joomla!. Joomla! is a wrapper around your software, it provides many usefull features like user authentication and so on. Since developers usually test their components only through Joomla!, they tend to forget about the possibility of calling files directly.
  • (Strip unwanted characters,invisible charaters)
  • Transcript

    • 1. Presented By Naveen Kumar Malla
    • 2. Agenda <ul><li>Web Application Security Threat Overview. </li></ul><ul><li>Common Attacks &amp; Preventative Techniques. </li></ul><ul><li>How Joomla handles each attack. </li></ul><ul><li>Writing secure web applications </li></ul>
    • 3. Web Application Security Threat Overview <ul><li>Often a web application is the only thing standing in the way of an attacker and sensitive business information </li></ul><ul><li>Web application attacks account for 2/3s of all attacks </li></ul><ul><li>Firewalls only stop network service attacks </li></ul><ul><li>Depending on the application an attacker may be able to: </li></ul><ul><li>– View or manipulate sensitive information </li></ul><ul><li>– Obtain unauthorized access to an application </li></ul><ul><li>– Be able to take control of the whole application </li></ul>
    • 4. Common Attacks &amp; Preventative Techniques <ul><li>Some of the common attack methods / strategies. </li></ul><ul><li>– Cross Site Request Forgery (CSRF) </li></ul><ul><li>– Cross Site Scripting (XSS) </li></ul><ul><li>– SQL Injections </li></ul><ul><li>– Avoid direct access to folders/code </li></ul><ul><li>– Register Globals </li></ul>
    • 5. CSRF <ul><li>A Cross Site Request Forgery (CSRF) attack relies on the trust a website has for a user to execute unauthorized requests and or transactions. </li></ul><ul><li>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&apos;s bank&apos;s website (rather than an image file), e.g., </li></ul><ul><li>&lt;img src=&amp;quot;http://bank.example/withdraw?account=chandu&amp;amount=1000000&amp;for=dhaval&amp;quot;&gt; </li></ul><ul><li>If Chandu&apos;s bank keeps his authentication information in a cookie, and if the cookie hasn&apos;t expired, then the attempt by Chandu&apos;s browser to load the image will submit the withdrawal form with his cookie, thus authorizing a transaction without Chandu&apos;s approval. </li></ul>
    • 6. How Joomla handles CSRF? <ul><li>POST Request: </li></ul><ul><li>POST requests are submitted in HTML using forms. In order to add the token to your form, add the following line inside your form: </li></ul><ul><li>&lt;?php echo JHTML::_( &apos;form.token&apos; ); ?&gt; This will output something like the following: </li></ul><ul><li>&lt;input type=&amp;quot;hidden&amp;quot; name=&amp;quot;1234567890abcdef1234567890abcdef&amp;quot; value=&amp;quot;1&amp;quot; /&gt; </li></ul><ul><li>Checking the Token: </li></ul><ul><li>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: </li></ul><ul><li>JRequest::checkToken() or die( &apos;Invalid Token&apos; ); </li></ul><ul><li>If the request is coming from the query string, you must specify this. The code then becomes: </li></ul><ul><li>JRequest::checkToken( &apos;get&apos; ) or die( &apos;Invalid Token&apos; ); </li></ul>
    • 7. XSS <ul><li>Cross Site Scripting (XSS) means executing script code (e.g. JavaScript) in a visitors browser. </li></ul><ul><li>Conclusion: </li></ul><ul><li>Use mosGetParam() for retrieving user input from a request, it does strip out a pretty good amount of insecure stuff. But don&apos;t rely on it, also take a good look at places where you echo out things to the webbrowser. Apply </li></ul><ul><li>$value = htmlspecialchars( $value ); </li></ul><ul><li>to strings before you echo them out to the browser. </li></ul><ul><li>Note: </li></ul><ul><li>Be carefull not to echo out any unvalidated input to a user. Code like this is dangerous for your visitors: </li></ul><ul><li>echo $_REQUEST[&apos;value&apos;]; </li></ul>
    • 8. SQL Injections <ul><li>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. </li></ul><ul><li>For Example: </li></ul><ul><li>$value = $_GET[&apos;value&apos;]; $database-&gt;setQuery( &amp;quot;SELECT * FROM #__mytable WHERE id = $value&amp;quot; ); </li></ul><ul><li>An attacker could hand over a string like &apos;1 OR 1&apos;, the query results in </li></ul><ul><li>&amp;quot;SELECT * FROM #__mytable WHERE id = 1 OR 1&amp;quot; </li></ul><ul><li>, thus returning all rows from jos_mytable. I&apos;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. </li></ul>
    • 9. To prevent SQL injections <ul><li>Force the type you want $sql = &apos;UPDATE #__mytable SET `id` = &apos; . (int) $int; </li></ul><ul><li>ALWAYS escape your strings $sql = &apos;UPDATE #__mytable SET `string` = &apos; . $db-&gt;quote( $db-&gt;getEscaped( $string ), false ); </li></ul><ul><li>Prevent DOS attacks </li></ul><ul><li>you can have a DOS vulnerability by not escaping the special wildcard characters % and _.  Joomla has a facility to do this for you!  $db-&gt;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: </li></ul><ul><li>$sql = &apos;UPDATE #__mytable SET .... WHERE `string` LIKE &apos;. $db-&gt;quote( $db-&gt;getEscaped( $string, true ), false ); </li></ul><ul><li>Preventing XSS Attacks </li></ul>
    • 10. Direct access to folders/code <ul><li>Instead of calling your component by </li></ul><ul><li>http:/ /www.example.com/index.php?option=com_yourcomponent , crackers also might try to use// // </li></ul><ul><li>http:/ /www.example.com/components/com_yourcomponent/yourcomponent.php </li></ul><ul><li>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: </li></ul><ul><li>&lt;?php </li></ul><ul><li>class myClass { [SomeFunctionsHere] } function myFunction() {[SomeCodeHere] } ?&gt; </li></ul><ul><li>Conclusion: </li></ul><ul><li>To make your component secure against direct access, insert this code line into the beginning of every PHP file that executes code: </li></ul><ul><li>// no direct access defined( &apos;_VALID_MOS&apos; ) or die( &apos;Restricted access&apos; ); </li></ul><ul><li>// no direct access defined(&apos;_JEXEC&apos;) or die(&apos;Restricted access&apos;); </li></ul>
    • 11. Register Globals <ul><li>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. </li></ul><ul><li>For example: </li></ul><ul><li>PHP could inject these sort of variables in a script </li></ul><ul><li>$username = &apos;hacked_username&apos;; </li></ul><ul><li>Now if a $username variable was already set this would overwrite it. </li></ul><ul><li>if ($authorized) { </li></ul><ul><li>//show members only page </li></ul><ul><li>} </li></ul><ul><li>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 </li></ul><ul><li>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 . </li></ul>
    • 12. Writing Secure Web applications <ul><li>Sanitize browser input </li></ul><ul><li>Don&apos;t put everything in the HTML directory </li></ul><ul><li>Avoid the shell </li></ul><ul><li>&apos;hidden&apos; fields aren&apos;t </li></ul><ul><li>Use POST instead of GET </li></ul><ul><li>Validate on the server </li></ul><ul><li>Avoid real directory and file names </li></ul><ul><li>Use absolute path and filenames </li></ul><ul><li>Specify the open mode when opening a file </li></ul><ul><li>Log suspicious errors </li></ul>
    • 13. References <ul><li>http://docs.joomla.org </li></ul><ul><li>http://advosys.ca/papers/web/61-web-security.html </li></ul><ul><li>http://fscked.org/blog/fully-automated-active-https-cookie-hijacking </li></ul><ul><li>http://blogs.securiteam.com/index.php/archives/1268 </li></ul>
    • 14. Any Queries?
    • 15. Thank You

    ×