[mysql] is dit veilig genoeg?

donderdag 13 september 2001 19:58

gooi eerst nog even een AddSlashes() over je sessid.

Let wel op dat je dan geen "query modificate/tweede query" exploit kan doen, maar iemand zou misschien wel een opzettelijk verkeerd nummer voor de sessid kunnen invullen...

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]

Acties:

donderdag 13 september 2001 20:08

Wat gebeurt er als iemand iets anders dan een getal als $sessid geeft? Geen exploit maar het zal niet goed gaan.
En wel eens aan gedacht wat er gebeurt als er een erg lange string in $sessid staat? Wordt het eerste een limiet bereikt in de HTTP specificaties, in PHP, in de MySQL connectie, in de MySQL server zelf? Altijd leuk om dat soort dingen even te experimenteren, ook al vermoed je dat het wel los zal lopen.

Acties:

donderdag 13 september 2001 20:45

wat de waarde van $sessid wat http hangt af van:

1) protocol (GET, POST)
2) server settings

normaal: GET max 255 chars, maar echter afhankelijk van server, en POST zou in principe ongelimiteerd zijn (maar goed, daar zal ook wel een maximum zijn ingebakken in de server).

Voor mysql zal er ook wel een maximum query length gedefinieerd zijn en php zal elk formaat string wel aan kunnen zolang er natuurlijk geheugen beschikbaar is.

Voor PHP zou je in de source kunnen gaan bladeren en je hebt zo wie zo natuurlijk een maximum lengte van 2**32-1.

Altijd leuk om dat soort dingen even te experimenteren, ook al vermoed je dat het wel los zal lopen.

Altijd leuk om het in de source-code op te gaan zoeken... (je kan tenslotte apache's source, php's source en mysql's source gewoon downloaden). Kost alleen een beetje teveel tijd

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]

Acties:

donderdag 13 september 2001 20:57

Op donderdag 13 september 2001 20:08 schreef Infinitive het volgende:
normaal: GET max 255 chars, maar echter afhankelijk van server, en POST zou in principe ongelimiteerd zijn (maar goed, daar zal ook wel een maximum zijn ingebakken in de server).

POST maximum hangt in eerste instantie van de browser af, maar voor dit soort gevallen gaat dat natuurlijk niet op (dan moet je inderdaad naar de server kijken).

Altijd leuk om het in de source-code op te gaan zoeken... (je kan tenslotte apache's source, php's source en mysql's source gewoon downloaden). Kost alleen een beetje teveel tijd

Misschien moet je het ook nog zoeken in de connectieprotocollen.
Verder zal dit niet echt een backdoor zijn, maar toch goed om uit te zoeken wat er eventueel kan gebeuren.

Acties:

donderdag 13 september 2001 21:17

Topicstarter

okay thnx, maar waarom moet ik eigenlijk addslashen?

(het gebeurt hier automatisch zag ik, maar ik vraag me wel af waarom ik het zou moeten doen)

Acties:

donderdag 13 september 2001 21:20

SELECT users.id,users.username FROM users INNER JOIN sessions ON users.id = sessions.userid WHERE sessions.session = '87' OR 'hoi'='hoi';

Voor de duidelijkheid:

$sessid = "87' OR 'hoi'='hoi"

Of bijv

$sessid = "12'; DELETE FROM users;'"

Acties:

donderdag 13 september 2001 21:22

Je moet addslashen omdat (als de slashen niet gedaan worden) iemand expres i.p.v. een nummer iets met de slashen doet, als in:

code:

1	SELECT nummer FROM tabel WHERE id='$nummer'.

nu zet ik b.v. in $nummer:

code:

1	1'; DROP TABLE tabel; SELECT '1

De query die je dan uiteindelijk krijgt wordt dan:

code:

1	SELECT nummer FROM tabel WHERE id='1'; DROP TABLE tabel; SELECT '1'

Dit zijn 3 geldige mysql queries en zullen ook uitgevoert worden. De eerste doet gewoon iets normaals, de tweede echter doet iets wat je waarschijnlijk niet wilt en de laatste query is er alleen maar om het netjes af te sluiten.

Dit is alleen maar even om aan te geven wat je allemaal kan. Normaal gesproken zou een DROP TABLE nooit uitgevoert worden want een oplettende php scripter zorgt ervoor dat de username die zijn script gebruikt om bij de database te kunnen geen rechten heeft tot ALTER TABLE, DROP TABLE, etc... hoewel, hoeveel mensen zullen het zijn die werkelijk netjes de beveiliging regelen?

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]

Acties:

donderdag 13 september 2001 21:33

Ik weet niet zeker of je via een MySQL API functie meerdere queries in een keer kan meegeven (en of ze daadwerkelijk uitgevoerd worden), ik meen mij te herinneren van niet. Desalniettemin is het zeker belangrijk dit even goed uit te zoeken.

Acties:

vrijdag 14 september 2001 08:07

Net even getest, het lijkt erop dat het erachter plakken van een tweede query niet werkt (en dat is eigenlijk maar goed ook). Echter, je kan nog steeds gaan rommelen met de eerste query, zoals iets maken als:

code:

1	SELECT ... FROM ... WHERE ... OR 1='1'

putStr $ map (x -> chr $ round $ 21/2 * x^3 - 92 * x^2 + 503/2 * x - 105) [1..4]

Acties:

vrijdag 14 september 2001 13:46

Topicstarter

thnx, ik snap het ja......

Maar als je 'magic_quotes_gpc' op ON staan dan hoef je het toch niet handmatig te doen of wel?

Acties:

kvdveer

Z.O.Z.

een idee is om je sessieID te laten bestaan uit een getal. Voordat je de boel uit het databeest haalt converteer je het getal wel echt een getal is...

Sowieso moet je heel erg uitkijken met queries waar direct een variabele uit de header wordt gebruikt. Dat geldt ook voor Perl,Asp,PHP,serverlets,NSAPI,ISAPI,etc...

_{nb. Ik heb geen PHP/MYSQL ervaring...}

Localhost, sweet localhost

woensdag 19 september 2001 20:53

Acties:

donderdag 20 september 2001 13:36

Topicstarter

Op donderdag 13 september 2001 21:17 schreef tomato het volgende:
SELECT users.id,users.username FROM users INNER JOIN sessions ON users.id = sessions.userid WHERE sessions.session = '87' OR 'hoi'='hoi';

Voor de duidelijkheid:

$sessid = "87' OR 'hoi'='hoi"

Of bijv

$sessid = "12'; DELETE FROM users;'"

Die geven bij mij parse errors, hmmz:

WHERE sessions.session = "87' OR 'hoi'='hoi";

Acties:

donderdag 20 september 2001 13:41

Topicstarter

^^

Acties: