I would say one of the best ways to guard against SQL injection is to use the excellent PEAR DB package. If you prepare() and execute() your queries, PEAR will automagically addslashes and handle the query depending on your RDBMS. And of course, for repeatable queries prepare and execute will give you a bit of a readability and speed increase.
Seguridad de Bases de Datos
Tabla de contenidos
- Diseñando la base de datos
- Conectándose a la base de datos
- Modelo de almacenamiento encriptado
- Inyección de SQL
Hoy en día, las bases de datos son componentes cardinales de cualquier aplicación basada en la web permitiendo a los sitios web que provean una variedad de contenido dinámico. Esta información muy sensible o secreta puede ser almacenada en una base de datos, por lo que debe considerar fuertemente proteger su base de datos.
Para devolver o almacenar cualquier información usted necesita conectarse a la base de datos, enviar una consulta legítima, devolver el resultado, y cerrar la conexión. Hoy en día, el lenguaje de consultas comunmente utilizado en esta interacción es el Lenguaje Estructurado de Consultas (SQL, por sus siglas en inglés). Vea como un atacante puede entrometerse con una consulta maliciosa de SQL.
Como puede suponer, PHP no protege su base de datos por sí mismo. Las siguientes secciones piensan ser una introducción a lo más básico de cómo acceder y manipular base de datos dentro de scripts de PHP.
Tenga en mente esta simple regla: Protección en profundidad. En la mayoría de sitios tome la acción de incrementar la protección de su base de datos, para una menor probabilidad de que un atacante tenga éxito en exponer o abusar de cualquier información que tenga almacenada. El buen diseño del esquema de la base de datos y de la aplicación se ocupará de sus mayores temores.
About offloading business logic to views and queries facilitated by the database engine, I seek to avoid this as much as possible, and only do so when such would drastically improve efficiency and user response time.
For instance, where I am there is database staff and application staff. Trying to do analysis on existent applications can easily become a snipe hunt.
The database should be kept discreet as much as possible from the application, such that any database or database provider can easily be substituted with a minimum of cognitive effort on the part of the one setting up a new database. If functionality has been offloaded to the database, additional testing is required to make sure triggers and views were done correctly, again, and that they work right.
Also, keeping all business logic with the application allows all functionality and documentation to be readable in one place, which is invaluable when doing subsequent analysis on an existing application. The worst thing is to have functionality scattered here and there.
Keeping everything with the application means one group of people is responsible, as in my case, application staff. Fewer requests go back and forth. Remember, anytime someone else is brought into the picture, such as asking a DBA to create a view or trigger for you, that DBA must take responsibility over his or her work, with whatever requirements, causing more bureaucracy and administrative complexity.
SQL injection could be prevented by inserting only base64_encoded data into the data base. Before searching the data base for a certain value or string base64_encode the search string and then start the query.
The posting below is at the very best extremely POV.
There is no more reason to assume you would want to change database vendor than there is to assume you might want to port your php code to Java for example. In either case, its going to be a matter of luck where your business rules sit.
Even if your business rules sit in your application, SQL is NOT portable. Oracle outer joins and pivot queries for example, can look completely different to those in other vendors software (particularly from 8i or lower). This fact alone means that changing your DB vendor requires work on your business rules either in the database or in the application.
Having your rules in the database and keeping the sql in application simple, will at least keep the work in the database if you need to change DB vendor. If you have the rules in the PHP, you'll have to change both.
Regarding where to put logic, it's really best not to be dogmatic about this. Putting logic in the db can have some security advantages but it has other security gotchas (for example, SQL injection inside a stored procedure may be possible in some environments). Similarly it can have some portability advantages and disadvantages.
The real question is that you want to ask what you want to be portable. If you put it in the db, it becomes easier to integrate programs written in different development environments with a minimum of security gotchas. If you put it in the application, then you have to create the interfaces on that level in middleware. Both approaches are doable. On the other hand if you are writing software you want to be deployable in MS SQL shops and Oracle shops, then you have to write portable SQL (avoiding gotchas) and put the logic in the application.
When we started rewriting the LedgerSMB codebase, we decided to move logic into the db because this would make it easier to retrofit security onto a very insecure codebase (by not trusting the application), and because we wanted to support languages other than Perl. A few years later this is bearing fruit and indeed I am reading the manual because I am writing integration libraries in PHP. I am not much of a PHP guy (I haven't programmed PHP since PHP 4.x) but I can write modules that let folks write code to interface securely with LedgerSMB's database logic. You can think of the stored procedures as being named queries which are shared between applications, or as API's to the database. But again, this approach is not universally applicable.
If portability between db's is not a major requirement, then I think the best approach is to do as much as possible in SQL queries and put those in the database. A couple hundred lines of SQL can replace a couple thousand lines in Perl or PHP, and is fundamentally easier to debug. Of course that won't work for everyone.
you can also chamge CHMOD for some file containing "user names" or "passwords"
On a database design point of view, you should make sure that you design databases in a manor that any query run from them need minimal input from the user and if it requires user input, that you encrypt where possible.
Encrypting user input doesn't do much to guard against SQL injection attacks. Naturally, you want to encrypt sensitive information across the wire, but if a user puts in malicious data into an input field, any encryption scheme will just dutifully unpack it at the other and and still run the SQL injection hack if you haven't guarded against it.
Encryption is not magic pixie dust to sprinkle on things to make them more secure.
you can keep your database vendor portable by using an encapsulation class such as adoDB for php or other framework like zend, codeigniter/cake/symphony,
it will add more header to the processing power (debatable) but it will far reduce the time to develop the app, and the DB.