Difference between #15 and #22 of Yii Security-extended guide

Yii Security-extended guide
security, tutorial, tips
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](https://www.owasp.org/index.php/SQL_Injection "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 the followings are some approachswhat do you do to
raise security guide:prevent these attacks in order to protect
your data, here is some suggestions:
<li>Input validation, do not trust any data from client side, always
<li>Avoid write raw SQL statement in controller, if you have to, pay great
attention to the input.</li>
<li>Use prepared statment,in Yii,<li>Place the query
in Model class, and use building methods in activeRecord
or CDbCommandlike find(),findAll() etc.</li>
<li>Use Criteria builder to pass
$params.</li>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.</li>

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

the followingsSo what are better some approachs to
raise security guide:the suggestions:
<li>Authorized the operation by checking the role of the user, consider
using <a href="http://www.yiiframework.com/doc/guide/1.1/en/topics.auth
">Role-Based Access Control (RBAC)</a>.
<li>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:
Input validation if the parameter can be validate against the potential thread,
do reluctance to trust user input.
Raise the level of access rule, leave the least privilege to users.
中文版请看[Yii框架开发安全考虑](http://yjlblog.com "yii