[PHP] Complete SQL van ene pagina naar andere, veilig?

[Rekcor]

Ik heb al veel posts/websites/blogs e.d. gelezen over SQL-injectie, maar ben nog geen antwoord op mijn vraag tegengekomen. Die luidt: is er een veilige manier om een complete SQL-string van de ene PHP-pagina naar de andere te loodsen? Dus een veilige variant van:

code:

http://www.mysite.com/myPage.php?sql=SELECT * FROM MyTable

Ik dacht aan het opslaan in $_SESSION (maar goed, die moet je dan wel super-supergoed beveiligen)

[gorgi_19]

session kan, maar die kan je alsnog kapen. Wat wil je bereiken?

[André]

Opslaan in een tijdelijke table?

[giMoz]

de beste beveiliging zit denkik hier in het design,

je moet niet het "loodsen" van de sql string van de ene pagina naar de andere pagina beveiligen,

je moet proberen te zorgen dat je het niet meer nodig is om een sql string naar een andere pagina te loodsen.... Dan is het nog veiliger

(persoonlijk kan ik me niet voorstellen dat je dit echt nodig hebt....)

[Rekcor]

gorgi_19 schreef op donderdag 08 maart 2007 @ 10:01:
session kan, maar die kan je alsnog kapen. Wat wil je bereiken?

Ik wil een pagina maken waarin je een of meerdere 'sql'-queries kunt stoppen (van buitenaf). De pagina genereert dan een mooi printbaar rapport met gegevens.

Opslaan in een tijdelijke tabel + een unieke ID meegeven en de ID dan versturen klinkt als een goed idee. In het ergste geval komt kwaadwillende persoon achter de ID, maar kan hij nog niet veel...

[TeeDee]

Dan nog kan ik me niet voorstellen dat je dit nodig hebt. Als het echt zo is, zou je kunnen filteren op de gebruikelijke SQL keywords die schadelijk kunnen zijn voor je DB.

[gorgi_19]

TeeDee schreef op donderdag 08 maart 2007 @ 10:08:
Dan nog kan ik me niet voorstellen dat je dit nodig hebt. Als het echt zo is, zou je kunnen filteren op de gebruikelijke SQL keywords die schadelijk kunnen zijn voor je DB.

Dan nog kan je je complete usertabel leegtrekken met wachtwoorden. Meestal zit er een MD5 beveiliging op, welke in een dagje wel te kraken is.

[KabouterSuper]

Je zou het hele sql-statement kunnen encoden, en op de ontvangende pagina weer kunnen decoden. Als je dit handig aanpakt, voorkom je in elk geval dat kwaadwillenden queries kunnen veranderen en uitvoeren.

Daarnaast loont het waarschijnlijk om een user te gebruiken die alleen leesrechten heeft. Zo kan niemand je database vernachelen. Als alternatief zou je het sql-statement kunnen doorzoeken op insert/delete/drop/etc en als je een van deze strings kunt vinden actie ondernemen.

[Rekcor]

giMoz schreef op donderdag 08 maart 2007 @ 10:03:je moet proberen te zorgen dat je het niet meer nodig is om een sql string naar een andere pagina te loodsen.... Dan is het nog veiliger

Hierin heb je gelijk. Je zou eigenlijk beter de resultaten van de query kunnen versturen. Dit zorgt wel voor meer dataverkeer...

[sariel]

Waarom zou je het willen? Ik kan me eigenlijk niet een situatie voorstellen waarbij je een complete SQL query naar een andere pagina zou willen sturen.
Stuur enkel een aantal waardes naar de andere pagina, en laat de tweede pagina de query opbouwen, als je het zo graag door de andere pagina wil laten doen.

[Janoz]

Als onderdeel van je ontwerp is dat je van buitenaf SQL queries in je applicatie wilt krijgen dan is het onmogelijk om dit veilig te krijgen. Je kunt je wel blind gaan staren om die tweede stap op te gaan lossen terwijl de fout gewoon in de eerste zit.

Conclussie: Back to the drawing board en maak maar een nieuw FO voor deze applicatie.

[Verwijderd]

inderdaad is dit bijna zo lek dat het de naam SQL-Injection niet zou mogen dragen.

wat je het beste kunt doen is niet de sql query overdragen maar de waardes voor die sql-query. die kun je dan het beste in een session-stoppen. session's zijn tenminste op een goeie server vluchtig en dus niet zomaar over te nemen. het enige wat er richting de client gaat is de session-id en die zou je nog kunnen beveiligingen middles https. en als iemand de /tmp/php-session-dir/ kan uitlezen op het file-system van je server heb je je over wat meer druk te maken dan alleen sql-injectie's etc.

bijvoorbeeld, maak een lijstje met table's die kunnen worden uitgelezen en stop die in een array. zorg dat de database die je gebruikt vast-staat zodat je script dus onmogelijk bijvoorbeeld de mysql database kan uitlezen waar de user-table enzo staat. dus dan krijg je zoiets:

PHP:

 mysql_connect("localhost", $user, $pass);
 mysql_select_db("mijnblog");

  $tables = array("forum", "frontpage", "blog", "reacties");
  if(!in_array($tables, $_session["sql_table"])){
   print("illegal table name for sql-report dump.");
   exit();
  }

  $sql = "Select * from ".$_session["sql_table"]."";
  $result = mysql_query($sql);
  
  // verwerk result en maak er een mooi raportje van.

het gaat erom dat je alles wat je van buiten, dus $_GET, $_POST maar ook $_SESSION gebruikt op geldigheid controlleert. je kunt er namelijk niet vanuit gaan dat er geen schadelijke waardes in zitten.

zelf zou ik voor de $_SESSION methode gaan omdat die alleen via het script kan worden gevuld, terwijl $_GET en ook $_POST via een simpele HTTP request kunnen worden aangepast.

[KabouterSuper]

Even een filosofische vraag: Kan er uberhaubt sprake zijn van sql-injection als je applicatie het toelaat om sql-statements uit te voeren. Ik zou zeggen van niet.

Edit: te laat.

Maar ik zie niet zo in waarom een applicatie per definitie onveilig is als het custom queries toelaat. Ik vind het een volstrekt logische eis dat een gebruiker de database wil benaderen zonder beperkt te zijn op wat voor manier dan ook. Handige GUI's die volledige vrijheid geven zijn erg zeldzaam, behalve dan GUI met een textearea waar ik mijn sql statement kan intikken.

Kan iemand mij een voorbeeld geven die valt onder het kopje "Onveilig"?

[ Voor 59% gewijzigd door KabouterSuper op 08-03-2007 10:41 ]

[Verwijderd]

en mocht je het toch via een POST,GET of weet ik veel doen. Zorg dan dat er alleen maar select statements gedaan mogen worden ofzo

[Rekcor]

Janoz schreef op donderdag 08 maart 2007 @ 10:22:Conclussie: Back to the drawing board en maak maar een nieuw FO voor deze applicatie.

Dat heb ik inderdaad gedaan . Het was meer de vraag of het uberhaupt kon (want dat zou veruit het gemakkelijkst en meest flexibel zijn). De oplossing van bijv. Docey mag dan wel veilig zijn, maar in feite kun je maar een - door de ontwerper vastgestelde - query draaien: SELECT *. Wat ik voor ogen was dat je iedere mogelijke SELECT-query kon versturen, dus met een willekeurig aantal JOINS, UNIONS, WHERE's etc.

Conclusie van onze samenspraak:

het verzenden van SQL queries is dermate riskant dat je een andere oplossing moet zoeken.

Mogelijke flexibele work-arounds:

• Query opslaan in database, uniek ID meegeven en alleen de ID versturen;
• Verstuur de resultaten van de query

Bedankt voor de hulp!

[KabouterSuper]

Ik ben het niet met je eens dat het riskant is. Kan iemand een definitie geven van veilig, riskant, en bij voorkeur een voorbeeld dat het onveilig is?

[Verwijderd]

KabouterSuper schreef op donderdag 08 maart 2007 @ 10:34:
Even een filosofische vraag: Kan er uberhaubt sprake zijn van sql-injection als je applicatie het toelaat om sql-statements uit te voeren. Ik zou zeggen van niet.

als je applicatie geen waardes die van buiten de applicatie/functie worden ontvangen direct in de query gebruikt dan is het antwoord dus nee, er kan geen sql-injection plaatsvinden.

zoals je kunt zien in mijn voorbeeld hierboven worden alleen waardes toegestaan die exact in de lijst met toegestane waardes voorkomen. dus zelfs als je de table naam met een hoofdletter zou schrijven dan wordt deze geweigerd en gaat de sql-injection niet door. dat is juist het idee van je applicate beschermen tegen sql-injection, zorgen dat er geen toegestane waardes kunnen worden gebruikt in een sql-query. dan kan er dus ook geen sql worden ge-injecteerd in de sql query.

vergeet ook niet dat er meerdere query's in 1 mysql_query kunnen worden gestopt. dit is een veel vergeten probleem. dus bijvoorbeeld $_session["sql_table"] bevat "'forum'" dan wordt de query:

code:

 Select * from 'forum';

maar stel dat ik de waarde van $_session["sql_table"] zou vervangen met "'forum'\"; drop forum;" dan wordt de sql query let vooral op de quoutes, als je die in je script toevoegt onstaat er een syntax error:

code:

 Select * from 'forum'; drop forum;

dan zal mysql_query zonder pardon 2 query uitvoeren. eerst zal hij de inhoud van forum laten zien en dat zal hij de table droppen. dat is dus wat een sql-injection doet en dat is wat het zo gevaarlijk maakt.

[ Voor 4% gewijzigd door Verwijderd op 08-03-2007 10:48 ]

[Cobalt]

Even een filosofische vraag: Kan er uberhaubt sprake zijn van sql-injection als je applicatie het toelaat om sql-statements uit te voeren. Ik zou zeggen van niet.

Waarschijnlijk is het niet de bedoeling dat gebruikers in staat zijn om eigen sql queries uit te voeren.

Als je één query voor twee pagina's wil gaan gebruiken dan hoef je de query niet naar de client te sturen. Je geeft aan dat je PHP gebruikt. Dan kan je ook de query die je wilt uitvoeren in één PHP bestand schrijven en dan dat bestand in beide PHP pagina's includen. Op deze manier blijft het binnen de server en dat is het veiligst.

[Rekcor]

KabouterSuper schreef op donderdag 08 maart 2007 @ 10:43:
Ik ben het niet met je eens dat het riskant is. Kan iemand een definitie geven van veilig, riskant, en bij voorkeur een voorbeeld dat het onveilig is?

De oplossing uit mijn eerste post lijkt me tamelijk onveilig...

[KabouterSuper]

Ik ben bekend met sql-injection, dus het voorbeeld van Docey was me bekend.

Maar als ik de queries uitvoer onder een user met alleen maar select rechten, zijn er dan nog veiligheids problemen?

[zwippie]

KabouterSuper schreef op donderdag 08 maart 2007 @ 10:34:
Even een filosofische vraag: Kan er uberhaubt sprake zijn van sql-injection als je applicatie het toelaat om sql-statements uit te voeren. Ik zou zeggen van niet.

Edit: te laat.

Maar ik zie niet zo in waarom een applicatie per definitie onveilig is als het custom queries toelaat. Ik vind het een volstrekt logische eis dat een gebruiker de database wil benaderen zonder beperkt te zijn op wat voor manier dan ook. Handige GUI's die volledige vrijheid geven zijn erg zeldzaam, behalve dan GUI met een textearea waar ik mijn sql statement kan intikken.

Kan iemand mij een voorbeeld geven die valt onder het kopje "Onveilig"?

UPDATE account SET credits = 1000000 WHERE user_id = 1045
DROP TABLE users;

Zoiets bedoel je?

[Verwijderd]

KabouterSuper schreef op donderdag 08 maart 2007 @ 10:46:
Ik ben bekend met sql-injection, dus het voorbeeld van Docey was me bekend.

Maar als ik de queries uitvoer onder een user met alleen maar select rechten, zijn er dan nog veiligheids problemen?

het probleem is vaak dat je van je hosting gewoon 1 account krijgt en die heeft volledige rechten op de database die bij jouw hosting hoort. vanuit het punt van veiligheid zou het inderdaad beter zijn maar op veel website's worden vaak zowel selects als insert en update query's gedaan.

echter zou het inderdaad beter zijn als er dan een aparte user was die dan wel de drop en alter rechten heeft terwijl de user die je voor je website gebruikt alleen select, insert en update rechten heeft. alleen veel hosting's zitten er niet op te wachten om het aantal accounts wat ze moeten beheeren te zien verduppelen.

[KabouterSuper]

zwippie, da's inderdaad een voorbeeld. Nu gaat het FO een rol spelen....is de functionele wens dat er alleen selects uitgevoerd kunnen worden, of moet het ook mogelijk zijn voor geautoriseerde gebruikers om deletes/updates/truncates/drops uit te voeren?

In het eerste geval (en hier ga ik vanuit) is het nogal voor de hand liggend om dit op het laagste niveau te regelen: de database. Alleen als dat niet kan, moet je het op applicatie niveau gaan regelen.

Dus als ik een select-only database-user heb, zie ik geen probleem.

@Reckor, geef me eens een definitie van onveilig. Waarom is de oplossing uit je eerste post 'tamelijk onveilig' (gegeven bovenstaand verhaal).

@Docey: dat zou wel roet in het eten gooien.

[ Voor 3% gewijzigd door KabouterSuper op 08-03-2007 10:58 ]

[Rekcor]

[b][message=27629601,noline]@Reckor, geef me eens een definitie van onveilig. Waarom is de oplossing uit je eerste post 'tamelijk onveilig' (gegeven bovenstaand verhaal).

Een situatie is onveilig als het risico groot is. Een bekende definitie van 'risico' is:

Risico = kans * schade

Aangezien je bij een gemiddelde webapplicatie op een gemiddelde webhost niet weet wat voor rechten de gebruiker heeft (lees/schrijf, etc) en aangezien dit meestal lees+schrijf blijkt te zijn, is de 'kans' m.i. best groot. De schade kan groot zijn en daarmee ook het risico en de onveiligheid.

[Janoz]

@KabouterSuper:

Enkel selectrechten kan ook nog gevaarlijk zijn:
Select gebruikersnaam, wachtwoord from gebruikers

[KabouterSuper]

Ok, als je een applicatie wilt draaien met een user waar je de rechten niet weet, dan ben ik het wel met de rest eens.

[Verwijderd]

Rekcor schreef op donderdag 08 maart 2007 @ 11:00:
[...]


Een situatie is onveilig als het risico groot is. Een bekende definitie van 'risico' is:

Risico = kans * schade

Aangezien je bij een gemiddelde webapplicatie op een gemiddelde webhost niet weet wat voor rechten de gebruiker heeft (lees/schrijf, etc) en aangezien dit meestal lees+schrijf blijkt te zijn, is de 'kans' m.i. best groot. De schade kan groot zijn en daarmee ook het risico en de onveiligheid.

beter kan ik het niet uitleggen

dus stel ik heb een script dat via een simpel GET variable een query opneemt en uitvoert dan is de kans dat ik die query kan uitvoeren bijna 100% immers bijna niets houdt mij tegen.

stel dat ik een mysql table heb genaamd 'users', waarin alle logins voor mijn druk bezochte website in staan. die website trekts wel 20 miljoen unique bezoekers per maand en alleen van de advertentie inkomsten ontvang ik al bijna een ton per dag. daarnaast ben ik ook bezig met onderhandeling om mijn website te verkopen aan een grote partij die er 1,19 miljard voor wil betalen.

todat, er in eens een maloot langs komt die "http://www.tubetoedeloe.nl/sql.php?query=drop table users" bezoekt. en daar gaan alle 20 miljoen logins. mensen kunnen niet meer inloggen en de site komt compleet tot stil stand. ook die grote partij die mij bijna 1,19 miljard wilde gaan betalen loopt weg.

dan is de schade = 0,999 * (1,19miljard + (365*100.000)) = 1.225.273.500 euro. lijkt me genoeg reden om eens wat meer naar de beveiliging van mijn site te gaan kijken.

[TeeDee]

gorgi_19 schreef op donderdag 08 maart 2007 @ 10:11:
[...]

Dan nog kan je je complete usertabel leegtrekken met wachtwoorden. Meestal zit er een MD5 beveiliging op, welke in een dagje wel te kraken is.

Klopt, ik had er eigenlijk nog iets bij moeten zetten als in: "False Sense of Security" of iets dergelijks.

[KabouterSuper]

Ach, ik zal wel enorm verwend zijn dat ik het usermanagement (en alle systeem tabellen) in een andere database user kan zetten, en verschillende gebruikers kan aanmaken voor verschillende rollen. En aan het voorbeeld van Docey te zien, mag ik ook in mijn handjes knijpen dat er backups gemaakt worden.

Ik blijf een sterke voorkeur houden om rechten zo laag mogelijk te regelen....de applicatie zelf vind ik eigenlijk al een niveau te hoog. Als iemand stukken van mijn source code kan zien/wijzigen, ben ik alsnog enorm het haasje.

[toost]

wat je eventueel nog zou kunnen doen is serverside de query in een bv. txt file opslaan. En deze dan weer in de volgende file benaderen. En met chmod (of htaccess?) zorgen dat alleen de creator het bestand kan aanpassen en dan zit je volgens mij ook vrij veilig (correct me if im wrong). In princiepe is dit het zelfde als de query in een temp dbase tabbel opslaan, maar het verschil is dat je nu niet in de dbase zit te werken dus kunnen kwaadwillige niet veel meer. (of ze moeten het voorelkaar krijgen om die tekstfile te kunnen editten).

Het enige wat je dan nog verder moet doen is per gecreate query een id laten generen en deze aan de bestandsnaam van een txt file koppellen bv. query324234.txt. En als je dan 324234 in je GET vars mee stuurt dan weet het volgende bestand in welke txt file hij moet gaan zoeken. En als het bestand klaar is of op een ander punt laat je je programma de txt file deleten zodat je geen vervuiling krijgt.

[Verwijderd]

toost schreef op donderdag 08 maart 2007 @ 13:59:
wat je eventueel nog zou kunnen doen is serverside de query in een bv. txt file opslaan. En deze dan weer in de volgende file benaderen. En met chmod (of htaccess?) zorgen dat alleen de creator het bestand kan aanpassen en dan zit je volgens mij ook vrij veilig (correct me if im wrong). In princiepe is dit het zelfde als de query in een temp dbase tabbel opslaan, maar het verschil is dat je nu niet in de dbase zit te werken dus kunnen kwaadwillige niet veel meer. (of ze moeten het voorelkaar krijgen om die tekstfile te kunnen editten).

Het enige wat je dan nog verder moet doen is per gecreate query een id laten generen en deze aan de bestandsnaam van een txt file koppellen bv. query324234.txt. En als je dan 324234 in je GET vars mee stuurt dan weet het volgende bestand in welke txt file hij moet gaan zoeken. En als het bestand klaar is of op een ander punt laat je je programma de txt file deleten zodat je geen vervuiling krijgt.

dat geeft weer 3 nieuwe problemen:
1) op veel servers draait apache deamon vaak als "nobody". ook draaien op shared hostings vaak alle accounts onder die zelfde "nobody" account. ook omdat er vaak alleen in de webroot van die hosting mag worden geschreven kan dan al vrij makkelijk de text-file gewoon worden gedownload en de directory structuur worden ontdenkt. als dan 1 account van je shared-hosting wordt gehack kun je dus als de text-file editten. daarnaast kan aan de query's ook duidelijk worden welke tabelnamen er worden gebruikt. geen goed idee dus.
2) file-locking. als je je even wat verdiept dan zie ja dat als een php-script de query-file niet goed lokt eerst het ene script een aantal bytes mag schrijven en dan het volgende. resultaat zijn queries die door me kaar heen zijn geschreven. daarnaast als de query-file wel goed lockt dan moet elke script wachten todat het voorgande script klaar is en de lock opheft. langere page-loads dus omdat de scripts op mekaar staan te wachten todat ze in dat bestand mogen schrijven.
3) file I/O. voor elke schrijf, lees, lock etc actie gaat er een request naar het file-system. zeker als de site een beetje druk is kan dit als snel een bottleneck worden en dus de page-loads nog verder omhoog schroeven. linux bevat wel enige opties zoals write-delay etc maar die zullen nooit zo goed werken als de caching en memory functies zoals die in een database worden gebruikt.

kortom slecht idee, slechte performance met veel veiligheids problemen. het werkt mischien goed op een dedicated hosting of een hosting waar elke hosting-account ook zijn eigen systeem user heeft middels suEXEC module bijvoorbeeld maar dan kun je net zogoed een mysql-user aanmaken met verminderde rechten wat inderdaad nog steeds de beste manier is. jammer dat weinig hostings dit leveren alleen veel dedicated hostings hebben deze mogelijkheid maar die zijn weer prijzig.

@kaboutersuper:
ik ben bang dat als iemand zijn site zo makkelijk openstelt voor sql-injection dat backups al helemaal een compleet onbekend fenomeen zijn. ja mischien 1x per jaar ofzo. schiet ook lekker op. en zelfs als er backups worden gemaakt mag je hopen dat dat incremental backups zijn en niet gewoon domweg eroverheen kopieren want anders zou je zonder pardon een backup van je database waarnet alle logins van zijn weggegooid over je oude backup heen zetten. maarja was een worst-case-scenerio

[ Voor 7% gewijzigd door Verwijderd op 09-03-2007 09:29 ]

[Michali]

Anders kun je ook proberen een eigen syntax te verzinnen en die te parsen. Dan kun je alleen toestaan wat jij wilt en toch heel flexibel zijn. Analyseer eens wat voor operaties er allemaal mogelijk moeten zijn. Zeer waarschijnlijk is het niet eens nodig om custom selectie statements te parsen.

[P.O. Box]

Of je geeft de webgebruiker alleen select rechten op je database en verplaatst je user-password tabel (en andere gevoelige tabellen) naar een andere database die alleen benaderbaar is voor de "checklogin"-routine...

[toost]

Verwijderd schreef op vrijdag 09 maart 2007 @ 09:23:
[...]


2) file-locking. als je je even wat verdiept dan zie ja dat als een php-script de query-file niet goed lokt eerst het ene script een aantal bytes mag schrijven en dan het volgende. resultaat zijn queries die door me kaar heen zijn geschreven. daarnaast als de query-file wel goed lockt dan moet elke script wachten todat het voorgande script klaar is en de lock opheft. langere page-loads dus omdat de scripts op mekaar staan te wachten todat ze in dat bestand mogen schrijven.

Met Punt 1 en 3 ben ik het helemaal eens, dat klopt. Maar punt 2 gaat zoizo niet op. Dan heb je mijn verhaal niet goed gelezen. Ik had het niet over 1 txt file maar over meerdere, per query request of hoe je het ook wilt noemen maakt hij een id. Dit id stuurt hij in de $_GET mee naar de volgende pagina en dit id wordt ook gebruikt in de filename dus bv. queryID.txt (query324234.txt). En dan gaat punt twee al niet meer op. En goed op een site die veel bezoekers trekt moet je een dergelijke opzet ook niet gebruiken Dus wat dat betreft vind ik punt 3 voor deze situatie specifiek ook niet erg sterk (puur naar de situatie gekeken).

[pietje63]

(Ik heb niet alle replies gelezen)

Wat ik zou doen is de query zelf in een database opslaan en dan een url als query.php?query_id=32 meesturen.

[Rekcor]

En nog een vraagje: stel je draait je site alleen op localhost, is het dan wel veilig om de queries te versturen via post/get? En op een intranet?

Je kunt dan bijv. eisen dat alleen gebruikers die op het lokale netwerk zitten (of dus op de pc waar de server op draait) queries mogen posten...

P.S. Even een los vraagje: weet iemand hoe phpMyAdmin dit oplost?

[SH4D3H]

Op PMA moet je inloggen?
Dus als je een geldige username en password hebt, wordt je als 'veilige persoon' gezien en mag je alles doen (mits je de juiste rechten hebt).

[Garyu]

Rekcor schreef op maandag 12 maart 2007 @ 10:19:
En nog een vraagje: stel je draait je site alleen op localhost, is het dan wel veilig om de queries te versturen via post/get? En op een intranet?

Je kunt dan bijv. eisen dat alleen gebruikers die op het lokale netwerk zitten (of dus op de pc waar de server op draait) queries mogen posten...

Jij bent er zeker van dat lokale gebruikers dit soort dingen nooit kunnen doen?

P.S. Even een los vraagje: weet iemand hoe phpMyAdmin dit oplost?

[Rekcor]

SH4D3H schreef op maandag 12 maart 2007 @ 10:26:
Op PMA moet je inloggen?
Dus als je een geldige username en password hebt, wordt je als 'veilige persoon' gezien en mag je alles doen (mits je de juiste rechten hebt).

Inderdaad. Alleen degene die

- site-admin rechten heeft
- op het lokale netwerk zit

mag queries posten

[StratoFarmer]

Als je maximale flexibiliteit wilt bieden en toch heel veilig dan zou ik kiezen voor een eigen mini taal die je om kunt zetten naar sql statements. Is wel wat werk, maar je hoeft je uiteindelijk veel minder zorgen te maken over beveiliging/opslag etc. Het 'Interpreter' design pattern dus eigenlijk.

[Knutselsmurf]

Kan iedere gebruiker van je site deze functie gebruiken, of is dat een beperkte set gebruikers?
Een applicatiebeheerder heeft meestal toch al voldoende rechten om het hele systeem om zeep te helpen
Je kunt bijvoorbeeld een systeem maken waarbij de applicatiebeheerder zelf queries kan maken, welke dan in de database worden gezet. Andere gebruikers kunnen deze queries dan alleen uit laten voeren.

Het belangrijkste is, dat je er zorg voor draagt dat de grote boze buitenwereld geen queries kan maken/uitvoeren, maar geautoriseerde gebruikers wel. Op dat moment kun je de queries best doorgeven met GET/POST

[FragFrog]

Knutselsmurf schreef op maandag 12 maart 2007 @ 10:39:
Het belangrijkste is, dat je er zorg voor draagt dat de grote boze buitenwereld geen queries kan maken/uitvoeren, maar geautoriseerde gebruikers wel. Op dat moment kun je de queries best doorgeven met GET/POST

Met stom is ^^

Maar de vraag is dan weer, waarom zou je zoiets schrijven als je ook gewoon PhpMyAdmin kan gebruiken?

Overigens zou ik post gebruiken of desnoods get met urlencode in zo'n geval. Tenzij je met AJAX aan de slag gaat heb je sowieso niet zo gek veel andere opties (ook als je't in een database wilt opslaan zul je anders alsnog eerst een post moeten doen om de gegevens te verzenden naar je opslaan-in-database-script )

[Verwijderd]

Janoz schreef op donderdag 08 maart 2007 @ 11:12:
@KabouterSuper:

Enkel selectrechten kan ook nog gevaarlijk zijn:
Select gebruikersnaam, wachtwoord from gebruikers

en daar is een heel simpele oplossing voor.... de tabel gebruikers niet in die zelfde DB doen.

[Verwijderd]

StratoFarmer schreef op maandag 12 maart 2007 @ 10:36:
Als je maximale flexibiliteit wilt bieden en toch heel veilig dan zou ik kiezen voor een eigen mini taal die je om kunt zetten naar sql statements. Is wel wat werk, maar je hoeft je uiteindelijk veel minder zorgen te maken over beveiliging/opslag etc. Het 'Interpreter' design pattern dus eigenlijk.

en dat is dus absolut niet veilig. dat is "security trough obsecurity" en daarvan is bewezen dat het niet werkt. enkel als toevoeging op een al veilige beveiliging.

het probleem blijft bestaan, het probleem waar het hele SQL-injectie gevaar omdraait. het feit dat gebruikers directe en ongecontroleerde elementen kunnen toevoegen aan je sql-query. en of dat nou in sql gebeurt of in een eigen ontworpen taal die wordt omgezet naar een sql-query maakt dan ook niet uit.

waar het wel bij kan helpen is dat het makkelijker wordt om de sql te controlleren. je zou bijvoorbeeld een vast-teken kunnen opnemen in je taal dat als einde van de query wordt gezien. en de omzetting limiteren tot een enkele query of bijvoorbeeld alleen maar 1 enkele where-clausule toelaten.

het belangrijkste is dat je NOOIT input direct mag gebruiken in de opbouw van je sql-query. als je daar als niet aan voldoet dan is elke andere beveiliging zinloos. controlleren wat de user je toestuurt is de enige manier om een sql-injectie te voorkomen.

@Toost: sorry had je post niet gelezen dat je meerder files gebruikte, wat overigens nog slechter is voor de disk I/O dan een enkele file, maarja dan zit je weer met het file-locking issue.

@pietje63: dat zou een goede manier zijn de query door te geven nadat deze is gecontrolleerd en opgebouwd. vergeet alleen niet dat je de query MOET deleten na dat deze is gebruikt en om ook een Time-To-Live waarde mee te geven zodat de query BINNEN N-Seconden moet worden gebruikt en anders als ongeldig wordt gezien. ook zou je een cron-job moeten hebben die alle querie's verwijderd die immiddels de TTL zijn gepasseerd.


@Reckor: localhost is alleen toegangkelijk vanuit de machien zelf. de inhoud van het verkeer maakt dus niet uit. de packetjes zullen nooit de machine verlaten. een IP-LOCK zou werken maar uit-eindelijk moet je toch de input controlleeren en waar die vandaan komt maakt dan ook niet meer uit.

PMA past zich inderdaad aan aan de rechten van de ingelogde gebruiker.

@Raceeend123: bij mysql zitten de rechten altijd in een aparte database en veel hostings maken 1 database per account aan. en 1 gebruiker per account die alleen en enkel rechten heeft op die database. wat hier de beste oplossing zou zijn om een 2e gebruiker aan te maken en die enkel de benodigde rechten te geven op de database die bij die account hoort. 2 gebruikers dus, 1 voor de site admin en 1 voor alleen deze speciale benodigdheid.

[daniëlpunt]

gorgi_19 schreef op donderdag 08 maart 2007 @ 10:01:
session kan, maar die kan je alsnog kapen. Wat wil je bereiken?

Ik dacht dat sessie's niet te kapen waren. Alleen het sessie ID word in een tijdelijk cookie opgeslagen, maar daar kan niks gedaan mee worden.

[gorgi_19]

super-muffin schreef op dinsdag 13 maart 2007 @ 13:45:
[...]
Ik dacht dat sessie's niet te kapen waren. Alleen het sessie ID word in een tijdelijk cookie opgeslagen, maar daar kan niks gedaan mee worden.

quote: http://msdn2.microsoft.com/en-us/library/ms972338.aspx

If a hacker were able to capture, or guess, the session ID cookie in use by an active session, he or she could submit valid HTTP requests that included this cookie. In this manner a hacker could hijack, or steal, a user's active session. For example, if a user had supplied valid credit card information, and an ASP script stored this information in the Session object, a hacker who managed to hijack the session could make purchases using the stolen session. If an application requires strong security, a number of techniques can be employed.