Yii Security-extended guide

You are viewing revision #15 of this wiki article.
This version may not be up to date with the latest version.
You may want to view the differences to the latest version.

next (#22) »

This article is called extended guide is because there is already a security guide in the Yii tutorial security section. but that guide is not complete in the sense that it does not rise the developers' attention to some other commonly happening attacks: SQL injection and magic URL, which can be major vulnerabilities in your application without much caring.

Warning: please do not consider this page as reference material. Its content is subject to caution. See comments at the bottom of the page.

SQL Injection

Sql injection is the most common attacks in the web application and has been ranked as the number 1 security issues by the OWASP. these attacks happen when you take input from users client side, and use it as a string in your raw SQL query. This attack can modify, delete data, and even exposes and manipulate all the sensitive data from the database.

One simple example could be:

"Select * from User where username=".$username;

This query is sinful because the attacker can easily inject query expression in the input $username which you take from client side. So imagin if user is capable of guessing your query and that user's input is "'john' or 1=1", then the whole query becomes:

"Select * from User where username='john' or 1=1";

and this query will return all the user data in your table, so attacker can do whatever they want with the data. This is a simple example, but it demonstrates very well of how the attack happens.

So what do you do to prevent these attacks in order to protect your data, here is some suggestions:

  1. Input validation, do not trust any data from client side, always validate.
  2. Avoid write raw SQL statement in controller, if you have to, pay great attention to the input.
  3. Place the query in Model class, and use building methods like find(),findAll() etc.
  4. Use Criteria builder to query data from your database, because all strings that are fed into the criteria are treated as strings, so database engine will not run them as sql language.

Magic Url

Another attack that you should pay attention to is the so called Magic Url. this attack happens when developers use parameters in the url as input and execute some operation on the server side. In particular, the architecture of Yii framework has opens the door to this attack. Without proper authentication guides and other countermeasures, attackers may be able to delete all the data you have in your database. so let's look at a concrete example:

Imagin you have a ImageController which contains common methods:

Class ImageController extends Controller{
    public function accessRules(){
         array('allow',	'actions'=>array('delete'),'users'=>array('*'),
    public function actionCreate(){
    public function actionDelete($id){

If you look at the structure, you can see that this controller allows authenticated user to perform the action delete. So one scenario would be that users click on the delete button under a image on the interface then the image record will be removed from database table. But wait, is this that simple? If you have knowledge about the http url, then a url for this delete action would probably be


or similar. It becomes clear now if your database design is just simply numerically increase the id for image records, then the obvious attack could happen just by simply changing the id value in the URL and remove the image record owned by another user, therefore this is a sinful code.

So what are the suggestions:

  1. Authorized the operation by checking the role of the user, consider using Role-Based Access Control (RBAC).
  2. Avoid using get method when the result has side effect on the server side,use post instead and always check if it is a post request by checking: Yii::app()->request->isPostRequest
  3. Input validation if the parameter can be validate against the potential thread, do reluctance to trust user input.
  4. Raise the level of access rule, leave the least privilege to users.
6 6
Viewed: 30 808 times
Version: Unknown (update)
Category: Tips
Written by: bingjie2680
Last updated by: bingjie2680
Created on: Nov 17, 2011
Last updated: 12 years ago
Update Article


View all history

Related Articles