• A request generated from a user’s browser without the user’s knowledge
• Relies on web site trust of logged-in users
• An attack involves tricking a user into transmitting ‘bad’ html with a request, which then returns sensitive data to the attacker
• Executed via iframes, xmlhttprequest calls or embedded in tags such as <script>, <object>, <embed>, <img>, …
<input type="hidden" name="item_id" value="123" />
<input type="hidden" name="quantity" value="1" />
• Use a unique form token in a hidden input field to verify the request
• Require re-login before sensitive operations (ex: financial)
• Regenerate the session id upon login, before authentication, using session_regenerate_id(true). passing boolean true removes the old session and is critical as a counter measure
• Also, regenerate session id prior to “critical” operations
• Use ssl encryption for the login, or assign a hidden key (not as good)
• Check that the ip address remains the same (although not always reliable)
• Use short session timeout
• Provide user logout
• Destroy an old and create a new session with: session_regenerate_id(true)
• Set php configuration directive session.use_only_cookies = 1
The configuration directive cgi.force_redirect prevents anyone from calling PHP directly with a URL like http://my.host/cgi-bin/php/secretdir/script.php. Instead, PHP will only parse in this mode if it has gone through a web server redirect rule. PHP older than 4.2.0 used –enable-force-cgi-redirect compile time option for this.
Usually the redirection in the Apache configuration is done with the following directives:
Action php-script /cgi-bin/php
AddHandler php-script .php
This option has only been tested with the Apache web server, and relies on Apache to set the non-standard CGI environment variable REDIRECT_STATUS on redirected requests. If your web server does not support any way of telling if the request is direct or redirected, you cannot use this option and you must use one of the other ways of running the CGI version.
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. Continue reading Cross Site Scripting
SQL injection is a technique often used to attack databases through a website. This is done by including portions of SQL statements in a web form entry field in an attempt to get the website to pass a newly formed rogue SQL command to the database (e.g. dump the database contents to the attacker). SQL injection is a code injection technique that exploits a security vulnerability in a website’s software. The vulnerability happens when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed. SQL commands are thus injected from the web form into the database of an application (like queries) to change the database content or dump the database information like credit card or passwords to the attacker. SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL database.
• SQL code is injected into the sql query
• Allows attacker to do almost anything the database user is permitted
• Example sql statement will return all the data from the ‘users’ table:
$sql = "SELECT * FROM users WHERE
username='$user' AND password='$pass'";
$user and $pass contain the value ' OR 1=1"
• Further attack possibilities: insert data, delete data, read data, denial of service…
• Use prepared statements when supported by the database
• Use database-specific escaping functions when creating the sql statement ex: mysqli_real_escape_string()
• Addslashes() is not a sufficient approach