[TYPO3-dev] Improvement against SQL injections

[ries van Twisk]

On Jun 16, 2007, at 1:51 PM, Lars Houmark wrote:

> 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
>
> _______________________________________________
>

hey Lars,

just a thought... there are a couple of SSO extensions on TER
that can create FE/BE users on the fly. How would this be handled?

Will there be a API created an extension can call to update the file?

Ries