[TYPO3-dev] Improvement against SQL injections

[Lars Houmark]

On 16/06/07 17:46, in article
mailman.330265.1182008818.21067.typo3-dev at lists.netfielders.de, "ries van
Twisk" <typo3 at rvt.dds.nl> wrote:

> I am not to sure how much it would really help, although
> I don't understand it completely.
> 
> we you are trying to prevent is unauthorized access to the BE if a set
> of tables is not valid, right?
> 

Maybe I have not explained myself good enough. I'll try again.

I am not trying to solve SQL injections directly. I acknowledge the fact
that we cannot directly prevent SQL injections, because we cannot be sure
that the core is at all handling the SQL query, and because of that, someone
may use this flaw to gain further access.

Let me explain a typical hacker scenario:

1. The hacker finds an extension with a SQL injection flaw.
2. The hacker writes a sneaky SQL query which uses this flaw to add another
backend user, by adding a new row in the be_users table.
(The above can be done VERY VERY easy and takes less than 30 seconds.)
3. Now the hacker has backend access (remark: as an admin user) and can do
very bad things.

I am trying to remove the possibility of adding a new row in the be_users
table which gives the backend access. Acknowledging that we cannot prevent
that hacker from adding the new row, I basically want to make the row
invalid, because it has not been added/updated through the backend
interface. This is what the checksum array is taking care of, along with
some minor improvements to the add/edit and login functions in the core.

Get what I want to do?

In the future - 5.0 I think - I hope that we are able to prevent these
things in the query by having better integrity in the entire system, but
this is not possible at the moment, because we can NEVER be sure that the
extension is written after the CGL, making the core functions able to filter
malicious data. In the macina_banners case, the ONE line of code which had
the SQL injection flaw was using a NON DBAL query.

- Lars