Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <h2>Cross-Site Request Forgery (CSRF)</h2> <h3>Description :</h3> <p>The basic idea is to trick a user to a page where his browser will initiate a POST or GET request to the CMS you attack.</p> <p>Imagine you know the email of a CMS powered site administrator. Email him some funny webpage with whatever you want in it. In this page, you craft a form with the data used by the admin panel of the CMS to create a new admin user. Send those data to the website admin panel, with the result in a hidden iframe of your webpage. Voilà, you got your own administrator account made.</p> <h3>How to prevent it :</h3> <p>The usual way is to generate random short-lived (15mn to hour) nonce in all your forms. When your CMS receive a form data, it checks first if the nonce is alright. If not, the data is not used.</p> <h3>CMS examples :</h3> <ul> <li><a href="http://www.secuobs.com/secumail/btsecumail/msg19456.shtml" rel="noreferrer">CMS made simple</a></li> <li><a href="http://developer.joomla.org/security/news/293-20090301-core-multiple-xsscsrf.html" rel="noreferrer">Joomla!</a></li> <li><a href="http://www.cvedetails.com/cve/CVE-2008-1981/20081981-vulnerable-softwares-references-exploits.html" rel="noreferrer">Drupal</a></li> <li><a href="http://heine.familiedeelstra.com/modx-csrf-woes-arbitrary-code-execution" rel="noreferrer">ModX</a></li> </ul> <h3>More information :</h3> <p>On the <a href="http://en.wikipedia.org/wiki/Cross-site_request_forgery" rel="noreferrer">wikipedia</a> page and on the <a href="http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29" rel="noreferrer">OWASP project</a>.</p> <h2>Bad password storing</h2> <h3>Description :</h3> <p>Imagine your database get hacked and published on something like wikileak. Knowing that a big part of your users use the same login and password for a lot of websites, do you want them to be easy to get ?</p> <p>No. You need to mitigate the damages done if your database datas become public.</p> <h3>How to prevent it :</h3> <ul> <li>A first idea is to hash them. Which is a bad idea because of <a href="http://en.wikipedia.org/wiki/Rainbow_table" rel="noreferrer">rainbow tables</a> (even if the hash is not md5 but sha512 for example).</li> <li>Second idea : add a unique random salt before hashing so the hackers has to bruteforce each password. The problem is, the hacker can compute a lot of hash fast.</li> <li>So, the current idea is to make it slow to hash the passwords : you don't care because you don't do it often. But the attacker will cry when he gets from 1000 hash generated per ms to 1.</li> </ul> <p>To ease the process, you can use the library <a href="http://www.openwall.com/phpass/" rel="noreferrer">phpass</a> developped by some password guru.</p> <h3>CMS examples :</h3> <ul> <li>Joomla! : salted md5</li> <li>ModX : md5</li> <li>Typo3 : <a href="http://bugs.typo3.org/view.php?id=10873&amp;nbn=5" rel="noreferrer">cleartext</a></li> <li>Drupal : switched to phpass after <a href="http://drupal.org/node/29706#comment-342450" rel="noreferrer">this discussion</a>.</li> </ul> <h3>More information :</h3> <p>The <a href="http://www.openwall.com/phpass/" rel="noreferrer">phpass page</a>.</p> <h2>Cross Site Scripting (XSS)</h2> <h3>Description</h3> <p>The goal of these attacks, is to make your website display some script which will be executed by your legitimate user.</p> <p>You have two kind of these : persistent or not. The first one comes usually from something your user can save, the other count on parameters given by a request sent. Here is an example, not persistent :</p> <pre><code>&lt;?php if(!is_numeric($_GET['id'])){ die('The id ('.$_GET['id'].') is not valid'); } ?&gt; </code></pre> <p>Now your attacker can just send links like <code>http://www.example.com/vulnerable.php?id=&lt;script&gt;alert('XSS')&lt;/script&gt;</code></p> <h3>How to prevent it</h3> <p>You need to filter everything you output to the client. The easiest way is to use <a href="http://php.net/manual/en/function.htmlspecialchars.php" rel="noreferrer">htmlspecialchars</a> if you don't want to let your user save any html. But, when you let them output html (either their own html or some generated from other things like bbcode) you have to be very careful. Here is an old example using the "onerror" event of the img tag : <a href="http://www.securityfocus.com/archive/1/511047" rel="noreferrer">vBulletin vulnerability</a>. Or you have the old <a href="http://en.wikipedia.org/wiki/Samy_%28XSS%29" rel="noreferrer">Myspace's Samy</a>.</p> <h3>CMS examples :</h3> <ul> <li><a href="http://www.securityfocus.com/archive/1/511178" rel="noreferrer">CMS made simple</a></li> <li><a href="http://www.getmura.com/index.cfm/blog/mura-cms-xss-vulnerability-fix/" rel="noreferrer">Mura CMS</a></li> <li><a href="http://seclists.org/fulldisclosure/2009/Mar/115" rel="noreferrer">Drupal</a></li> <li><a href="http://modxcms.com/forums/index.php/topic,47759.0.html" rel="noreferrer">ModX</a></li> </ul> <h3>More information :</h3> <p>You can check <a href="http://en.wikipedia.org/wiki/Cross-site_scripting" rel="noreferrer">wikipedia</a> and <a href="http://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29" rel="noreferrer">OWASP</a>. You also have a lot of XSS vector on <a href="http://ha.ckers.org/xss.html" rel="noreferrer">ha.ckers</a> page.</p> <h2>Mail header injection</h2> <h3>Description :</h3> <p>Mail headers are separated by the CRLF (<code>\r\n</code>) sequence. When you use some user data to send mails (like using it for the From: or To:) they can inject more headers. With this, they can send anonymous mails from your server.</p> <h3>How to prevent it :</h3> <p>Filter all the <code>\n</code>, <code>\r</code>, <code>%0a</code> and <code>%0d</code> characters in your headers.</p> <h3>CMS examples :</h3> <ul> <li><a href="http://www.mail-archive.com/bugtraq@securityfocus.com/msg22509.html" rel="noreferrer">Jetbox CMS</a></li> </ul> <h3>More information :</h3> <p><a href="http://en.wikipedia.org/wiki/E-mail_injection" rel="noreferrer">Wikipedia</a> is a good start as usual.</p> <h2>SQL Injection</h2> <h3>Description :</h3> <p>The old classic. It happen when you form a SQL query using direct user input. If this input is crafted like needed, a user can do exactly what he want.</p> <h3>How to prevent it :</h3> <p>Simple. Don't form SQL queries with user input. Use <a href="http://en.wikipedia.org/wiki/Parametrized_query#Parameterized_statements" rel="noreferrer">parameterized queries</a>. Consider any input which is not coded by yourself as user input, be it coming from the filesystem, your own database or a webservice for example.</p> <h3>CMS example :</h3> <ul> <li><a href="http://drupal.org/node/65357" rel="noreferrer">Drupal</a></li> <li><a href="http://secunia.com/advisories/20874" rel="noreferrer">Joomla!</a></li> <li><a href="http://secunia.com/Advisories/33405/" rel="noreferrer">ModX</a></li> <li><a href="http://www.securityfocus.com/archive/1/510066" rel="noreferrer">Pars CMS</a></li> </ul> <h3>More information :</h3> <p><a href="http://en.wikipedia.org/wiki/SQL_injection" rel="noreferrer">Wikipedia</a> and <a href="http://www.owasp.org/index.php/SQL_Injection" rel="noreferrer">OWASP</a> have really good pages on the subject.</p> <h2>Http response splitting</h2> <h3>Description :</h3> <p>Like e-mail headers, the http headers are separated by the CLRF sequence. If your application uses user input to output headers, they can use this to craft their own.</p> <h3>How to prevent it :</h3> <p>Like for emails, filter <code>\n</code>, <code>\r</code>, <code>%0a</code> and <code>%0d</code> characters from user input before using it as part of a header. You can also <a href="http://php.net/manual/en/function.urlencode.php" rel="noreferrer">urlencode</a> your headers.</p> <h3>CMS examples :</h3> <ul> <li><a href="http://www.securityfocus.com/bid/23851/discuss" rel="noreferrer">Drake CMS</a></li> <li><a href="http://plone.org/products/cachefu/issues/88" rel="noreferrer">Plone CMS</a></li> <li><a href="http://www.securiteam.com/unixfocus/6X00B0ABFE.html" rel="noreferrer">Wordpress</a></li> </ul> <h3>More information :</h3> <p>I'll let you guess a little as to where you can find a lot of infos about this kind of attack. <a href="http://www.owasp.org/index.php/HTTP_Response_Splitting" rel="noreferrer">OWASP</a> and <a href="http://en.wikipedia.org/wiki/HTTP_response_splitting" rel="noreferrer">Wikipedia</a>.</p> <h2>Session hijacking</h2> <h3>Description :</h3> <p>In this one, the attacker want to use the session of another legitimate (and hopefully authenticated) user. For this, he can either change his own session cookie to match the victim's one or he can make the victim use his (the attacker's) own session id.</p> <h3>How to prevent it :</h3> <p>Nothing can be perfect here : - if the attacker steal the victim's cookie, you can check that the user session matches the user IP. But this can render your site useless if legitimate users use some proxy which change IP often. - if the attacker makes the user use his own session ID, just use <a href="http://php.net/manual/fr/function.session-regenerate-id.php" rel="noreferrer">session_regenerate_id</a> to change the session ID of a user when his rights change (login, logout, get in admin part of the website etc.).</p> <h3>CMS examples :</h3> <ul> <li><a href="http://forum.joomla.org/viewtopic.php?p=1522329" rel="noreferrer">Joomla!</a> and <a href="http://seclists.org/fulldisclosure/2008/Sep/414" rel="noreferrer">Drupal</a></li> <li><a href="http://securityreason.com/securityalert/2866" rel="noreferrer">Zen Cart</a></li> </ul> <h3>More information :</h3> <p><a href="http://en.wikipedia.org/wiki/Session_hijacking" rel="noreferrer">Wikipedia</a> page on the subject.</p> <h2>Other</h2> <ul> <li>User DoSing : if you prevent bruteforcing of login attempt by disabling the usernames tried and not the IP the attempts come from, anyone can block all your users in 2mn. Same thing when generating new passwords : don't disable the old one until the user confirm the new one (by loging with it for example).</li> <li>Using user input to do something on your filesystem. Filter this like if it was cancer mixed with aids. This concern the use of include and require on files which path is made in part from the user input.</li> <li>Using <a href="http://www.php.net/manual/en/function.eval.php" rel="noreferrer">eval</a>, <a href="http://www.php.net/manual/en/function.system.php" rel="noreferrer">system</a>, <a href="http://www.php.net/manual/en/function.exec.php" rel="noreferrer">exec</a> or anything from this kind with user input.</li> <li>Don't put files you don't want web accessible in web accessible directory.</li> </ul> <p>You have a lot of things you can read on the <a href="http://www.owasp.org/index.php/Category:Attack" rel="noreferrer">OWASP</a> page.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload