Using the object-relational mapping (ORM) framework is of positive significance to SQL injection. The best way to fight against SQL injection is to use the precompiled bind variables. There is, however, a difficulty in dealing with SQL injection: When there are many applications and a large number of codes, it is difficult to identify SQL injection. The ORM framework provides a convenient solution to this problem.
Take iBATIS in the ORM framework, for example, which is based on sqlmap. The generated SQL statements are structured to be in the XML file. iBATIS supports dynamic SQL and can insert dynamic variables $value$ in the SQL statement; if the user can control this variable, then there will be an SQL injection vulnerability:
<select id="User.getUser" parameterClass="cn.ibatis.test.User" resultClass="cn.ibatis. test.User"> select TABLE_NAME,TABLESPACE_NAME from user_tables where table_ name like '%'||#table_ name#||'%' order by $orderByColumn$ $orderByType$ </select>
The static variables #value# are safe, so when using iBATIS, we only need to search inside all sqlmap files for dynamic variables. When there is a need to use dynamic SQL, you can deal with it as a special case; for example, in the upper code logic, strictly control that variable to ensure there is no injection problem. In Django, it is even simpler. The Database API, provided by Django, has made an SQL escape for all inputs by default, such as
foo.get_list(bar__exact="' OR 1=1")
The ultimate effect is similar to
SELECT * FROM foos WHERE bar = '\' OR 1=1'
Using the functions provided by the web framework, it is more consistent in the code style and also more conducive for code auditing.