-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Garvin Hicking schrieb:
Hi!
i don't know ... if this is really a security problem we should consider give our forms a token - and proceed only with valid token
IMHO SQL should be escaped (and I wonder it is not).
Actually that's not a solution to the problem. PMA needs to be fed SQL commands, and we need to accept the via POST.
yes, but we should escape it before displaying in browser
The only way to not allow XSRF/CSRF is to put tokens into the form. BUT putting token into the form means to things:
- We need to utilize sessions. Only via sessions, form tokens could be easily
implemented, because a server-token needs to be compared with a client-token.
sessions already utilized
- Implementing the tokens might be needed on virtually every <form> PMA has.
That'a a buttload full of work to do. ;)
this can easily be implemented via PMA_generate_common_hidden_inputs();
also this token needs to be sent with get-requests/links
- -- Sebastian Mendel
www.sebastianmendel.de
Hi!
Actually that's not a solution to the problem. PMA needs to be fed SQL commands, and we need to accept the via POST.
yes, but we should escape it before displaying in browser
Ah, I overread that. Yes, escaping SQL when displaying it would be wise.
- We need to utilize sessions. Only via sessions, form tokens could be
easily implemented, because a server-token needs to be compared with a client-token.
sessions already utilized
Seems I missed that, too. Since when does PMA use sessions, and what are they currently used for? Did I also miss session saving of large SQL queries when browsing rows to get rid of the "?" editing buttons and max-GET-length exceeded problems?
Best regards, Garvin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Garvin Hicking schrieb:
Hi!
Actually that's not a solution to the problem. PMA needs to be fed SQL commands, and we need to accept the via POST.
yes, but we should escape it before displaying in browser
Ah, I overread that. Yes, escaping SQL when displaying it would be wise.
- We need to utilize sessions. Only via sessions, form tokens could be
easily implemented, because a server-token needs to be compared with a client-token.
sessions already utilized
Seems I missed that, too. Since when does PMA use sessions, and what are they
2.8
currently used for? Did I also miss session saving of large SQL queries when
no, this is not done at the moment
only request independent data is saved in session, data that does not change if someone uses multiple windows with phpMyAdmin, this is currently only configuration and themes
browsing rows to get rid of the "?" editing buttons and max-GET-length exceeded problems?
i do not know this problem!? wasn't this fixed with 'subforms'?
- -- Sebastian Mendel
www.sebastianmendel.de
On Thu, 20 Apr 2006 11:23:34 +0200 (CEST) "Garvin Hicking" phpmyadmin@supergarv.de wrote:
Ah, I overread that. Yes, escaping SQL when displaying it would be wise.
This is already done and works fine.