[PHP] Logingegevens controleren bij externe server

[Atmoz]

Hallo mede-Tweakers,

Voor een projectje ben ik bezig met het ontwikkelen van een soort login-systeem.

Ik heb thuis een webservertje (Apache) waar ik PHP op kan draaien.

Op een externe host (bijvoorbeeld op de Ziggo of UPC webspace) wil ik een kleine HTML of PHP website hebben.
Daar kun je een Gebruikersnaam + Wachtwoord invullen. Als je dan vervolgens op "Login" drukt moeten beide (naam + ww) naar de server thuis worden gestuurd zodat ik ze daar kan "opvangen" en verder kan behandelen in mijn (nog te maken) executable die er weer iets mee doet.

Mijn probleem is nu: hoe krijg ik die naam + wachtwoord thuis op de server? Ik had zelf een klein PHP scripje in gedachte wat op de host (Ziggo of UPC) draait. Dit moet er dan voor zorgen dat de gegevens worden doorgestuurd naar de webserver thuis, en er tevens voor zorgen dat het IP adres van de thuisserver niet zichtbaar is voor diegene die inlogt op de website. Ook niet voor hackers dus!! Als ik dan thuis weer een PHP script heb wat als parameters de naam + wachtwoord kan hebben, dan kan vervolgens de executable worden aangeroepen wat de rest van het proces in gang zet.

Heeft er iemand een idee hoe dit aan te pakken?

Ik kan op de externe host wel een PHP script maken wat als parameter de naam + wachtwoord accepteert, maar dan ziet iedereen direct waar het heen (het IP van de thuis server) wordt gestuurd, en bovendien staat die informatie dan ook in de history van de browser, en kan de volgende gebruiker op die pc makkelijk het wachtwoord + gebruikersnaam achterhalen.

Hopelijk is het hele verhaal een beetje duidelijk

[Verwijderd]

Kan je geen EXE maken op je thuis-server die op een poort luistert? Dan moet je webapplicatie een connectie maken op die poort en zo de gegevens doorsturen. Ofwel moet je een webservice opzetten in PHP op je thuisserver die deze gegevens kan behandelen. Je moet daarbij wel opletten dat de gegevens beveiligd verzonden worden met een encryptie zodat er minder kans is dat je logingegevens achterhaald kunnen worden.

[Mike2k]

http://www.google.nl/#hl=...42698f41&biw=1680&bih=845

Keywords: PHP en NTLM

[ Voor 8% gewijzigd door Mike2k op 19-01-2012 12:34 ]

[Verwijderd]

Een webservice schrijven?
http://www.brainbell.com/...HP_5's_SOAP_Extension.htm

[jopitan]

Zoek eens op het internet naar PHP + CURL
Hiermee kun je posts/headers sturen naar een bepaald IP- en domeinadres.
Je kunt met CURL er zelfs voor zorgen dat er uiteindelijk een SSL certificaat moet worden gebruikt.

Als je bijvoorbeeld WAMP hebt geinstalleerd zit CURL er al standaard bij in en hoef je het alleen nog maar aan te zetten. En dan je script zo bouwen dat ie requests stuurt bij het verzenden. CURL geeft daarnaast ook weer data terug die je uiteindelijk weer kunt gebruiken als SUCCES of FAIL.

Zo kun je bijvoorbeeld CURL ook gebruiken om in te loggen op een andere website en dan bijvoorbeeld de complete content terug te halen en weer te geven op je pagina.

http://php.net/manual/en/book.curl.php

Hier:
http://www.php.net/manual/en/curl.examples-basic.php
kun je de URL vervangen met die van jou en de parameters met de username en wachtwoord meegeven.


PHP scriptje ziggo -> CURL request naar je home met de parameters -> Home Server checkt in MySQL database of ze bestaan -> Bestaan? -> Start executable (op de home server) -> Home Server echo't dat de gegevens kloppen en de executable is gestart -> CURL geeft een return -> PHP scriptje ziggo geeft resultaat weer

[ Voor 41% gewijzigd door jopitan op 19-01-2012 13:00 ]

[RobIII]

Even terug naar de basis; hoe is dit anders dan dat je een andere resource als (zeg) een MySQL server gebruikt? In 't "ziggo PHP-tje" spreek je gewoon een externe resource aan, of dat nou een MySQL server is die je credentials meegeeft of weer een andere resource (je thuisserver) die je dan toevallig over HTTP ofzo laat babbelen.

Wat je als onderliggende techniek gebruikt is dan een implementatiedetail. Dat kan CURL zijn met het POST-en van wat zut of SOAP (babbelt lekker met een selfhosted WCF executable bijvoorbeeld) of you-name-it.

[ Voor 31% gewijzigd door RobIII op 19-01-2012 12:54 ]

[Atmoz]

Wow, dat is al heel wat bruikbare info wat hierboven allemaal gegeven wordt Echt super! Thanks.
Als je niet weet wat je zoekt, dan zoek je tot je een ons weegt....

RobIII schreef op donderdag 19 januari 2012 @ 12:52:
Even terug naar de basis; hoe is dit anders dan dat je een andere resource als (zeg) een MySQL server gebruikt? In 't "ziggo PHP-tje" spreek je gewoon een externe resource aan, of dat nou een MySQL server is die je credentials meegeeft of weer een andere resource (je thuisserver) die je dan toevallig over HTTP ofzo laat babbelen.

Ik was in eerste instantie "bang" dat die gegevens (naam + ww) op de een of andere manier makkelijk te achterhalen waren. Als je de broncode van de pagina bekijkt mag daar niet het IP adres van de thuis server te zien zijn. En natuurlijk moeten eerder ingevulde inlognamen en wachtwoorden niet in de history terug te vinden zijn.

Dus ik direct op verkenning uit. De bovenstaande manieren klinken meer dan interessant

[jopitan]

atmoz schreef op donderdag 19 januari 2012 @ 13:16:
Ik was in eerste instantie "bang" dat die gegevens (naam + ww) op de een of andere manier makkelijk te achterhalen waren. Als je de broncode van de pagina bekijkt mag daar niet het IP adres van de thuis server te zien zijn. En natuurlijk moeten eerder ingevulde inlognamen en wachtwoorden niet in de history terug te vinden zijn.

Dus ik direct op verkenning uit. De bovenstaande manieren klinken meer dan interessant

PHP is in principe allemaal Server Sided.
Hier een simpel voorbeeldje voor je hoe het in PHP zou kunnen
Ikzelf preffer om alles in classes en methods te bouwen.

PHP:

$_db_host = "127.0.0.1";
$_db_user = "Username";
$_db_pass = "Password";
$_db_base = "Database";
mysql_connect($_db_host, $_db_user, $_db_pass);
mysql_select_db($_db_base);
$_rows = mysql_num_rows(mysql_query("SELECT * FROM gebruikers WHERE `nickname`='$_nickname' AND `wachtwoord`='$_hashedpass'"));
if($_rows == 1) {
echo 1;
} else {
echo 0;
}

[Atmoz]

jopitan schreef op donderdag 19 januari 2012 @ 13:28:
[...]

PHP is in principe allemaal Server Sided.
Hier een simpel voorbeeldje voor je hoe het in PHP zou kunnen
Ikzelf preffer om alles in classes en methods te bouwen.

En daarmee bedoel je neem ik aan dat als er naar de broncode wordt gekeken, dan het IP adres (de URL) naar/van de thuisserver niet zichtbaar is? (de PHP staat veilig op de server, en alleen de output wordt naar de client gestuurd)

Dus dan is het opzich wel veilig om op die manier simpel 2 strings (gebruikersnaam + wachtwoord) naar de thuisserver te sturen? Of kan een hacker dit dan toch makkelijk achterhalen?

[RobIII]

atmoz schreef op donderdag 19 januari 2012 @ 13:38:
Of kan een hacker dit dan toch makkelijk achterhalen?

De gemiddelde scriptkiddie: waarschijnlijk niet.
De die-hard überhacker: waarschijnlijk wel. Of die er zin in heeft, de tijd er voor heeft en denkt dat 't de moeite waard is is een tweede.

Wat wil je nou horen?

[Atmoz]

RobIII schreef op donderdag 19 januari 2012 @ 13:53:
[...]

De gemiddelde scriptkiddie: waarschijnlijk niet.
De die-hard überhacker: waarschijnlijk wel. Of die er zin in heeft, de tijd er voor heeft en denkt dat 't de moeite waard is is een tweede.

Wat wil je nou horen?

Perfect, dat is precies wat ik wilde horen!

ALS hij zich dus al de tijd en moeite ervoor neemt, en het lukt uiteindelijk, dan kan hij nog maar alleen de gegevens van één gebruiker achterhalen. Aan de rest van de gegevens (van de andere 100 gebruikers) kan hij toch niet.

Dus het hoeft niet helemaal 100% Pentagon "top secret" safe te zijn
(er staat immers maar informatie van één gebruiker tegelijk op de webserver thuis)

[jopitan]

atmoz schreef op donderdag 19 januari 2012 @ 13:59:
[...]


Perfect, dat is precies wat ik wilde horen!

ALS hij zich dus al de tijd en moeite ervoor neemt, en het lukt uiteindelijk, dan kan hij nog maar alleen de gegevens van één gebruiker achterhalen. Aan de rest van de gegevens (van de andere 100 gebruikers) kan hij toch niet.

Dus het hoeft niet helemaal 100% Pentagon "top secret" safe te zijn
(er staat immers maar informatie van één gebruiker tegelijk op de webserver thuis)

Een die-hard hacker had het pentagon anders gehackt hoor.
Maar het is inderdaad gewoon veilig. Daarnaast zou ik in je script er wel een hash overheen gooien met een blowfish erbij ofzo. En dus de wachtwoord gehasht opslaan. Ikzelf ga meestal voor een SHA512 hash.

[Atmoz]

jopitan schreef op donderdag 19 januari 2012 @ 14:01:
[...]


Een die-hard hacker had het pentagon anders gehackt hoor.

Ohja, das waar ook

Maar het is inderdaad gewoon veilig. Daarnaast zou ik in je script er wel een hash overheen gooien met een blowfish erbij ofzo. En dus de wachtwoord gehasht opslaan. Ikzelf ga meestal voor een SHA512 hash.

Even om dit voor mij duidelijk(er) te maken:
Ik snap dat gehasht opslaan (veel) veiliger is. Maar is dit niet alleen nodig als je bang bent dat je database met wachtwoorden erin gehackt kan worden? (c.q. als deze online ergens staat?)

Of kan er ergens een "sniffer" geplaatst worden zodat een 3e persoon deze data ruw en ongecodeerd over de lijn ziet gaan?

In feite gaat de data (het wachtwoord) vanuit de gebruiker via de webserver (Ziggo webspace) naar de thuisserver. Dus een hacker zal er al tussen moeten gaan zitten om deze data te kunnen "zien".

Zoals je ziet, ik weet er wel IETS van, maar er zijn nog altijd veel dingen waar ik vraagtekens bij heb...
In ieder geval wederom thanks voor de hulp. Ik kom steeds dichter bij de eindoplossing

[kwaakvaak_v2]

Ik snap dat gehasht opslaan (veel) veiliger is. Maar is dit niet alleen nodig als je bang bent dat je database met wachtwoorden erin gehackt kan worden? (c.q. als deze online ergens staat?)

Hij staat toch online? Dat jij het adres van de server probeert geheim te houden doet daar niets aan af. Mijn IP adress van ziggo wordt dagelijks meerdere malen bekeken door scriptkiddies om te zien of ik niet stiekum een webserver open heb staan op dat ip adress. Dus als jij je zaakjes thuis niet goed op orde hebt, en de 'hacker' vind een open poort bij je, installeerd zijn topsecret l33t h@x0r5 scriptje via een exploit.. Tada.. alles op straat.

Moraal van het verhaal, bij beveiligingen, dus ook hashes, nooit de aanname doen dat er toch niemand achter kan komen.

[Atmoz]

kwaakvaak_v2 schreef op donderdag 19 januari 2012 @ 14:56:
[...]


Hij staat toch online?

Nee. Hij staat niet online
Met online versta ik namelijk dat er een fysieke TCP/IP verbinding is tussen de gebruikers (thuis achter hun PC surfend op mijn bij Ziggo gehost websitetje) en mijn database. En dat is er niet.
Bij de thuis server stopt het TCP/IP verkeer. Op die server staat ook niets van SQL of wat dan ook...
Via een andere speciale NON TCP/IP verbinding maakt deze server verbinding met een andere server waar dan die SQL DB op draait. In mijn ogen dus super veilig!

Dat jij het adres van de server probeert geheim te houden doet daar niets aan af. Mijn IP adress van ziggo wordt dagelijks meerdere malen bekeken door scriptkiddies om te zien of ik niet stiekum een webserver open heb staan op dat ip adress. Dus als jij je zaakjes thuis niet goed op orde hebt, en de 'hacker' vind een open poort bij je, installeerd zijn topsecret l33t h@x0r5 scriptje via een exploit.. Tada.. alles op straat.

Moraal van het verhaal, bij beveiligingen, dus ook hashes, nooit de aanname doen dat er toch niemand achter kan komen.

Duidelijk verhaal!
Alleen al om te leren omgaan met "hashen" ga ik het implementeren

[kwaakvaak_v2]

Define 'NON TCP/IP' eens, ik ben wel benieuwd wat je gebruikt. Postduif? Serieel?, briefjes via je moeder?

Ik bedoel meer dat ik niet zo overtuigd ben van je beveiliging namelijk. Uiteindelijk moet er een keertje verkeer plaats vinden tussen je server en een host. En tenzij je dat inderdaad manueel doet, zit daar altijd een geautomatiseerde slag tussen die hackable is.

[jopitan]

atmoz schreef op donderdag 19 januari 2012 @ 15:03:
[...]


Nee. Hij staat niet online
Met online versta ik namelijk dat er een fysieke TCP/IP verbinding is tussen de gebruikers (thuis achter hun PC surfend op mijn bij Ziggo gehost websitetje) en mijn database. En dat is er niet.
Bij de thuis server stopt het TCP/IP verkeer. Op die server staat ook niets van SQL of wat dan ook...
Via een andere speciale NON TCP/IP verbinding maakt deze server verbinding met een andere server waar dan die SQL DB op draait. In mijn ogen dus super veilig!


[...]


Duidelijk verhaal!
Alleen al om te leren omgaan met "hashen" ga ik het implementeren

Ik snap je lulkoek niet helemaal maar ik zie jouw schema nu zo:
Login Pagina (Ziggo Host Server) -> Home Server -> Database Server (ook ergens anders gehost?)

Maar dan staat je Login pagina online -> Je home server staat online want daar moet ie immers mee kunnen verbinden.

[CodeCaster]

atmoz schreef op donderdag 19 januari 2012 @ 15:03:
Via een andere verbinding maakt deze server verbinding met een andere server. In mijn ogen dus super veilig!

Waarom zou het toevoegen van een extra verbinding het geheel veiliger maken?

Zoals gezegd, ergens moet jouw PHP-script jouw thuisserver aanspreken. Die thuisserver luistert dus op een bepaalde poort, en die poort is niet alleen voor jouw server benaderbaar. Hint: dit kun je wel doen, door bijvoorbeeld alleen het IP van jouw Ziggo-server (of meervoud, als er iets van een CDN of loadbalancing bij komt kijken) toestaan.

Iedereen kan dus, als je dit niet afschermt, bij jouw thuisserver, en proberen via de bekende wegen jouw script te benaderen om zodoende je database leeg te trekken.

Vervolgens kan ook jouw script op de Ziggo-server nog gehackt worden, waarna men vrij spel heeft op de database (de hacker bevindt zich op dat moment namelijk op het 'vertrouwde' IP).

Kortom: hashen.

[Atmoz]

kwaakvaak_v2 schreef op donderdag 19 januari 2012 @ 15:18:
Define 'NON TCP/IP' eens, ik ben wel benieuwd wat je gebruikt. Postduif? Serieel?, briefjes via je moeder?

Ik bedoel meer dat ik niet zo overtuigd ben van je beveiliging namelijk. Uiteindelijk moet er een keertje verkeer plaats vinden tussen je server en een host. En tenzij je dat inderdaad manueel doet, zit daar altijd een geautomatiseerde slag tussen die hackable is.

Serieel inderdaad.
En dan met 2 zelfgemaakte executables (één op de thuis server, één op de SQL DB die ernaast staat).
Het communiceren gaat dan op een vrij "trage" manier zodat alles toch heel stabiel verloopt.
Verder vind er een zelfgemaakte/verzonnen encryptie plaats waardoor de data niet zomaar te "sniffen" is... (als de hacker al weet dat het via serieel gaat)

En verder is het natuurlijk zo dat je via serieel geen database aan de andere kant van de lijn kunt leeg gooien of bekijken. Hij (de hacker die heeft ingebroken op de thuisserver) kan dus niet meer informatie zien dan op dat moment via de serial port wordt overhevelt.

Ik hoor graag hoe jullie hierover denken, en of die inderdaad een redelijk veilige manier is.
Zelf ben ik namelijk van mening dat wanneer er een fysieke TCP/IP verbinding ligt, dat het veel meer voor de hand ligt om dit te hacken. Je moet er maar net op komen dat er gebruik wordt gemaakt van een seriële verbinding toch? Maar ik ben echt zéér benieuwd hoe jullie experts hiernaar kijken!

[jopitan]

CodeCaster schreef op donderdag 19 januari 2012 @ 15:26:
[...]
Vervolgens kan ook jouw script op de Ziggo-server nog gehackt worden, waarna men vrij spel heeft op de database (de hacker bevindt zich op dat moment namelijk op het 'vertrouwde' IP).

Kortom: hashen.

Om nog maar te zwijgen van een man in the middle.

Je kunt er beter altijd vanuit gaan dat er mensen je website proberen te hacken zodat ie altijd beveiligt is tegen rare snuiters van buitenaf.

Daarnaast is iets hashen niet moeilijk en vergt 1 simpele lijn aan PHP code

PHP:

$_variabel = hash("sha512", $input);

Met wat extra data zodat het nog lastiger is:

PHP:

$_hash = hash("sha512", $input);
$_variabel = $_hash . "bL0wf1zh" . str_rot13(substr($_hash, 0, 18));

[ Voor 22% gewijzigd door jopitan op 19-01-2012 15:40 ]

[Atmoz]

jopitan schreef op donderdag 19 januari 2012 @ 15:24:
[...]


Ik snap je lulkoek niet helemaal maar ik zie jouw schema nu zo:
Login Pagina (Ziggo Host Server) -> Home Server -> Database Server (ook ergens anders gehost?)

Maar dan staat je Login pagina online -> Je home server staat online want daar moet ie immers mee kunnen verbinden.

Zie hierboven, is mijns inziens geen lulkoek...

CodeCaster schreef op donderdag 19 januari 2012 @ 15:26:
[...]

Waarom zou het toevoegen van een extra verbinding het geheel veiliger maken?

Zoals gezegd, ergens moet jouw PHP-script jouw thuisserver aanspreken. Die thuisserver luistert dus op een bepaalde poort, en die poort is niet alleen voor jouw server benaderbaar. Hint: dit kun je wel doen, door bijvoorbeeld alleen het IP van jouw Ziggo-server (of meervoud, als er iets van een CDN of loadbalancing bij komt kijken) toestaan.

Iedereen kan dus, als je dit niet afschermt, bij jouw thuisserver, en proberen via de bekende wegen jouw script te benaderen om zodoende je database leeg te trekken.

Vervolgens kan ook jouw script op de Ziggo-server nog gehackt worden, waarna men vrij spel heeft op de database (de hacker bevindt zich op dat moment namelijk op het 'vertrouwde' IP).

Kortom: hashen.

Goed idee van dat IP adres! Staat genoteerd, en ga ik zeker ook toepassen.

Zelf denk ik dat het niet mogelijk is om via een seriële verbinding een database op een andere computer leeg te halen. Tenzij in dit topic dadelijk blijkt dat ik ongelijk heb natuurlijk...


[edit]

jopitan schreef op donderdag 19 januari 2012 @ 15:34:
[...]


Om nog maar te zwijgen van een man in the middle.

Je kunt er beter altijd vanuit gaan dat er mensen je website proberen te hacken zodat ie altijd beveiligt is tegen rare snuiters van buitenaf.

Uiteraard. Dat is ook weer zo. Ik ga dus hashen!

[ Voor 10% gewijzigd door Atmoz op 19-01-2012 15:38 ]

[CodeCaster]

atmoz schreef op donderdag 19 januari 2012 @ 15:34:
[...]


Serieel inderdaad.
En dan met 2 zelfgemaakte executables (één op de thuis server, één op de SQL DB die ernaast staat).
Het communiceren gaat dan op een vrij "trage" manier zodat alles toch heel stabiel verloopt.
Verder vind er een zelfgemaakte/verzonnen encryptie plaats waardoor de data niet zomaar te "sniffen" is... (als de hacker al weet dat het via serieel gaat)

En verder is het natuurlijk zo dat je via serieel geen database aan de andere kant van de lijn kunt leeg gooien of bekijken. Hij (de hacker die heeft ingebroken op de thuisserver) kan dus niet meer informatie zien dan op dat moment via de serial port wordt overhevelt.

Ik hoor graag hoe jullie hierover denken, en of die inderdaad een redelijk veilige manier is.
Zelf ben ik namelijk van mening dat wanneer er een fysieke TCP/IP verbinding ligt, dat het veel meer voor de hand ligt om dit te hacken. Je moet er maar net op komen dat er gebruik wordt gemaakt van een seriële verbinding toch? Maar ik ben echt zéér benieuwd hoe jullie experts hiernaar kijken!

Security through obscurity.

Ergens wordt een query ingeschoten. Of de query uiteindelijk in rooksignalen naar de database wordt gestuurd maakt niet uit; als je bijvoorbeeld niet aan escaping doet, gaat een query eindigend op "and password = '' or 1=1--" alsnog problemen opleveren.

Hoewel de seriële verbinding de sterkste schakel lijkt (maar hoe kom je in vredesnaam op het idee? Wat is er mis met de database gewoon op je Ziggo-server laten draaien?), is een keten alsnog zo sterk als de zwakste schakel. De hacker hóeft niets te weten van de laatste stap, zodra 'ie ergens anders iets kan vernachelen ga je alsnog de boot in.

[ Voor 10% gewijzigd door CodeCaster op 19-01-2012 16:20 ]

[Atmoz]

CodeCaster schreef op donderdag 19 januari 2012 @ 15:40:
[...]

Security through obscurity.

Ergens wordt een query ingeschoten. Of de query uiteindelijk in rooksignalen naar de server wordt gestuurd maakt niet uit; als je bijvoorbeeld niet aan escaping doet, gaat een query eindigend op "and password = '' or 1=1--" alsnog problemen opleveren.

Hoewel de seriële verbinding de sterkste schakel lijkt (maar hoe kom je in vredesnaam op het idee? Wat is er mis met de database gewoon op je Ziggo-server laten draaien?), is een keten alsnog zo sterk als de zwakste schakel.

Daar heb je gelijk in. Maar daarom is er ook niets of niemand die "handmatig" query's gaat maken...
Het zijn allemaal (zijn er maar een paar) vaste querry's waar niets aan te veranderen valt. Het paswoord is altijd even lang, dus als er nog iets achter zou staan (kan eigenlijk al niet aangezien de PasswordTextBox aan bepaalde strenge eisen zal voldoen) dan strip ik er dat gewoon uit. Op die manier komt er alleen maar een string van 8 chars (enkel a t/m z chars, dus geen "=" tekens bijvoorbeeld) door welke via de serial port data ophaalt uit de SQL DB.

Het is een beetje "hokkie tokkie" maar is het niet veel veiliger dan alles via TCP/IP?

[edit]

CodeCaster schreef op donderdag 19 januari 2012 @ 15:40:
[...]

Hoewel de seriële verbinding de sterkste schakel lijkt (maar hoe kom je in vredesnaam op het idee? Wat is er mis met de database gewoon op je Ziggo-server laten draaien?), is een keten alsnog zo sterk als de zwakste schakel. De hacker hóeft niets te weten van de laatste stap, zodra 'ie ergens anders iets kan vernachelen ga je alsnog de boot in.

Een database op de Ziggo server zal sowieso vaak gehackt (of in ieder geval geprobeerd gehackt te) worden.
Een database ACHTER een seriele verbinding, ACHTER een thuis server, ACHTER een PHP script op een andere webserver zal minder snel gehackt worden. Ik ben blij dat er zoveel meegedacht wordt. Ga hierdoor zeker nog andere dingen overwegen!!!

[ Voor 24% gewijzigd door Atmoz op 19-01-2012 15:50 ]

[CodeCaster]

Ik moet de eerste hacker die het inlogform van de site zelf gebruikt nog tegenkomen.

Nee, dit is geenszins veiliger dan alles via TCP/IP.

[jopitan]

atmoz schreef op donderdag 19 januari 2012 @ 15:47:
[...]


Daar heb je gelijk in. Maar daarom is er ook niets of niemand die "handmatig" query's gaat maken...
Het zijn allemaal (zijn er maar een paar) vaste querry's waar niets aan te veranderen valt. Het paswoord is altijd even lang, dus als er nog iets achter zou staan (kan eigenlijk al niet aangezien de PasswordTextBox aan bepaalde strenge eisen zal voldoen) dan strip ik er dat gewoon uit. Op die manier komt er alleen maar een string van 8 chars (enkel a t/m z chars, dus geen "=" tekens bijvoorbeeld) door welke via de serial port data ophaalt uit de SQL DB.

Het is een beetje "hokkie tokkie" maar is het niet veel veiliger dan alles via TCP/IP?

[edit]


[...]


Een database op de Ziggo server zal sowieso vaak gehackt (of in ieder geval geprobeerd gehackt te) worden.
Een database ACHTER een seriele verbinding, ACHTER een thuis server, ACHTER een PHP script op een andere webserver zal minder snel gehackt worden. Ik ben blij dat er zoveel meegedacht wordt. Ga hierdoor zeker nog andere dingen overwegen!!!

Je moet gewoon bepalen wat voor tekens je wilt toestaan die in het veld mogen ingevuld worden. Stel je wilt alleen maar a-z en 0-9 toestaan maar geen speciale characters. Dan kun je simpel op het Ziggo Scriptje een Preg_match van PHP uitvoeren.

PHP:

if(preg_match("/^[a-zA-Z0-9]+$/", $input)) {
echo 'Jippie a jee cowboy, goed wachtwoord';
}

[Atmoz]

CodeCaster schreef op donderdag 19 januari 2012 @ 15:49:
Ik moet de eerste hacker die het inlogform van de site zelf gebruikt nog tegenkomen.

Nee, dit is geenszins veiliger dan alles via TCP/IP.

Dus gewoon toch de database direct via TCP/IP aan de hele wereld koppelen?
Als er dan iemand toegang heeft tot de thuisserver kan ik me heel goed voorstellen dat hij een dump maakt van de SQL database op de andere computer, of de hele DB zelfs leeg gooit...

Ik kan niet begrijpen dat het niet veiliger is om dit via een COM port te doen?! Dan kun je in ieder geval geen ernstige dingen doen met de database op de SQL server.

Dat het niet voor de hand ligt wat ik doe mag duidelijk zijn. Maar daarom hoeft het niet meteen "verkeerd" of minder veilig te zijn toch?

[edit]

jopitan schreef op donderdag 19 januari 2012 @ 15:53:
[...]


Je moet gewoon bepalen wat voor tekens je wilt toestaan die in het veld mogen ingevuld worden. Stel je wilt alleen maar a-z en 0-9 toestaan maar geen speciale characters. Dan kun je simpel op het Ziggo Scriptje een Preg_match van PHP uitvoeren.

PHP:

if(preg_match("/^[a-zA-Z0-9]+$/", $input)) {
echo 'Jippie a jee cowboy, goed wachtwoord';
}

Dat was inderdaad het idee.
Jij hebt het alleen vergemakkelijkt door meteen de code te geven.
Daarvoor uiteraard mijn dank

Sjiek om te zien dat er zoveel wordt meegedacht.
Ben heel benieuwd wat hier nu uit gaat komen.

Misschien moet ik straks het IP maar eens doorgeven, en dat jullie het dan vervolgens moeten hacken.
Diegene die het eerste de eerste regel in de database weet te vinden krijgt € 150,- ofzo.
Weet niet of dat van GoT uit mag, maar zoiets lijkt me wel een leuke test. (anders haal ik dit laatste gedeelte wel uit m'n post)

[ Voor 38% gewijzigd door Atmoz op 19-01-2012 15:56 ]

[jopitan]

atmoz schreef op donderdag 19 januari 2012 @ 15:54:
[...]


Dus gewoon toch de database direct via TCP/IP aan de hele wereld koppelen?
Als er dan iemand toegang heeft tot de thuisserver kan ik me heel goed voorstellen dat hij een dump maakt van de SQL database op de andere computer, of de hele DB zelfs leeg gooit...

Ik kan niet begrijpen dat het niet veiliger is om dit via een COM port te doen?! Dan kun je in ieder geval geen ernstige dingen doen met de database op de SQL server.

Dat het niet voor de hand ligt wat ik doe mag duidelijk zijn. Maar daarom hoeft het niet meteen "verkeerd" of minder veilig te zijn toch?

Gewoon alleen van je Ziggo Host het IP toelaten staan via de een open poort van je Home Server.
Als je bijvoorbeeld een mysql server gebruikt op je home server is de 3306 wel handig.
Alleen connecties toestaan van je Ziggo Hosts IP en 127.0.0.1/localhost natuurlijk

[Atmoz]

jopitan schreef op donderdag 19 januari 2012 @ 15:56:
[...]


Gewoon alleen van je Ziggo Host het IP toelaten staan via de een open poort van je Home Server.
Als je bijvoorbeeld een mysql server gebruikt op je home server is de 3306 wel handig.
Alleen connecties toestaan van je Ziggo Hosts IP en 127.0.0.1/localhost natuurlijk

Jep. Duidelijk!
Heel goed. Er komt natuurlijk ook een goede firewall op de home server, dus dat zal e.e.a. toch al wat moeilijker maken.

[Beatboxx]

Wat ik zou doen is het php script laten verbinden met een MySQL database die bij jou thuis draait. Je moet alles wel goed hashen, zelfs als de hacker achter de data komt, heeft ie er dan nog niks aan. Md5 of sha voldoet dus niet echt, daar zijn overal rainbow-tables van te vinden.

bcrypt.php

PHP:

require_once('bcrypt.php'):
$bcrypt = new Bcrypt(13); /*met de 13 kan je spelen om het minder veilig maar sneller te laten gaan, of juist hoger maken voor meer veiligheid maar langzamer */
/*pass uit login form */
$password = mysql_real_escape_string($_POST['password']); 
/*pass uit database */
$hash = $data['hash'];
$verify = $bcrypt->verify($password, $hash);
if($verify === true){ echo 'membercontent'; }

en register script

PHP:

require_once('bcrypt.php')
$bcrypt = new Bcrypt(13); 
$pass = mysql_real_escape_string($_POST['pass']);
$hash = $bcrypt->hash($pass);

[CodeCaster]

jopitan schreef op donderdag 19 januari 2012 @ 15:53:
[...]


Je moet gewoon bepalen wat voor tekens je wilt toestaan die in het veld mogen ingevuld worden. Stel je wilt alleen maar a-z en 0-9 toestaan maar geen speciale characters. Dan kun je simpel op het Ziggo Scriptje een Preg_match van PHP uitvoeren.

PHP:

if(preg_match("/^[a-zA-Z0-9]+$/", $input)) {
echo 'Jippie a jee cowboy, goed wachtwoord';
}

Nee, je moet gewoon escapen. Bovenstaande regex zorgt voor alles behalve goede wachtwoorden. Het was maar een voorbeeld.

atmoz schreef op donderdag 19 januari 2012 @ 15:54:
Dus gewoon toch de database direct via TCP/IP aan de hele wereld koppelen?
Als er dan iemand toegang heeft tot de thuisserver kan ik me heel goed voorstellen dat hij een dump maakt van de SQL database op de andere computer, of de hele DB zelfs leeg gooit...

Waarom? Als je puur MySQL naar buiten opengooit, heeft men het wachtwoord of een bekende exploit nodig om in je database te komen. De kans is klein dat dat gebeurt, maar het wordt om diverse redenen (o.a. een kleine kans is alsnog een kans) afgeraden.

Wat je dan wel kunt doen: een soort service maken in PHP, die de database gewoon aanspreekt zoals het hoort:

PHP:

function Login($user, $pass)
{
    $user = mysql_real_escape_string($user);
    $pass = mysql_real_escape_string(hash_functie($pass));
    
    $result = mysql_fetch_array(mysql_query("select userid from user where username='$user' and password='$pass'");
    
    return $result['userid'];
}

Zo is in de eerste plaats je database niet meer direct benaderbaar, en in de tweede plaats is het via deze functie onmogelijk om je database leeg te trekken. Dit is overigens geen best-practice-PHP, er zit nul error checking in en prepared statements zijn ook wel fijn.

Deze service roep je dan aan vanaf je website.

Ik kan niet begrijpen dat het niet veiliger is om dit via een COM port te doen?! Dan kun je in ieder geval geen ernstige dingen doen met de database op de SQL server.

Ik kan niet begrijpen dat je heil ziet in één stap níet via TCP/IP te doen terwijl de hele keten die daaraan voorafgaat dat wel doet. Dat haalt netto dus niets uit.

Behalve als deze twee executables de queries alsnog controleren, escapen en wat dies meer zij, maar dat kun je zonder zo veel gedoe net zo goed met een regeltje PHP-code doen, je voegt onnodig veel afhankelijkheden en moeilijkheden toe, die uiteindelijk niets toevoegen.

atmoz schreef op donderdag 19 januari 2012 @ 15:59:
[...]


Jep. Duidelijk!
Heel goed. Er komt natuurlijk ook een goede firewall op de home server, dus dat zal e.e.a. toch al wat moeilijker maken.

Een firewall maakt het niet automatisch veiliger, zeker niet als je doodleuk de poort in kwestie weer opengooit in die firewall.

[ Voor 4% gewijzigd door CodeCaster op 19-01-2012 16:19 ]

[kwaakvaak_v2]

tja... ik vind persoonlijk dat je erg moeilijk doet om niet te hoeven hashen, of te beveiligen. Tegen elk van je argumentent is met gemak een tegen argument te bedenken waarmee je beveiliging onderuit getrokken wordt.

Als een hacker de moeite genomen heeft om op je systeem in te breken, dan gaat ie ook wel de moeite nemen om te zien waar php de data naar toe stuurt. En ik gok dat het windows is, waarschijnlijk dot.net. Beetje decompileren en analyze van wat je .exe doet en tada... Daar gaat je Berlijnse seriele muur.

[RobIII]

Holy shit; dit is echt voor voer voor thedailywtf.com, met alle respect.
Ik kan hier maar 1 tip geven: doe 't gewoon op de 'gangbare' manier (en dan wel de goeie* manier); die Rube-goldberg methode die je nu aan 't fröbelen bent maakt 't geenszins veiliger en waarschijnlijk alleen maar on-veiliger danwel instabieler

Het is dat ik druk ben op 't moment, maar er zitten zó veel (potentiële) problemen in deze constructie dat je alleen maar vérder van huis bent dan wanneer je het doet zoals de rest van de wereld 't doet. En dat leer je door gewoon eens een goede tutorial door te nemen op verschillende vlakken; PHP, MySQL (of eender welk RDBMS), wat netwerk beheer/beveiliging etc.

* = Hashen, salten, correct escapen danwel parameterized queries gebruiken etc.

Tevens even een title-fix:
HTML / PHP - gebruikersnaam + wachtwoord versturen naar serv >> [PHP] Logingegevens controleren bij externe server

offtopic:
En dat is dan post 30.000 die ik hier maak

[ Voor 56% gewijzigd door RobIII op 19-01-2012 16:28 ]

[jopitan]

RobIII schreef op donderdag 19 januari 2012 @ 16:17:
En dat leer je door gewoon eens een goede tutorial door te nemen op verschillende vlakken; PHP, MySQL (of eender welk RDBMS), wat netwerk beheer/beveiliging etc.

* = Hashen, salten, correct escapen danwel parameterized queries gebruiken etc

offtopic:
En dat is dan post 30.000 die ik hier maak

-zucht- En toch ben ik het met Rob eens. Als ik jou was zou ik inderdaad even zelf op internet kijken hoe je dat soort dingen aan moet pakken. Want we kunnen alles wel lekker voorkauwen, maar daar heb je uiteindelijk niks aan.

offtopic:
Gefeliciteerd hoor, bij mij duurt dat nog wel even

[ Voor 13% gewijzigd door jopitan op 19-01-2012 16:48 ]

[Janoz]

Trouwens.... Je weet dat je op je Ziggo webspace helemaal geen php kunt draaien toch? (Zal voor UPC waarschijnlijk niet heel anders zijn) Er is dus waarschijnlijk helemaal geen mogelijkheid om op die plek wat serverside dingen af te handelen.

[jopitan]

Tegenwoordig heb je al domein + hosting (3GB webruimte met 60GB dataverkeer) voor maar 30 euro per jaar.
Zo zit ik bijvoorbeeld met een aantal hostings bij Antagonist.

[ Voor 1% gewijzigd door jopitan op 19-01-2012 16:56 . Reden: Jaar inplaats van maand ]

[Atmoz]

Beatboxx schreef op donderdag 19 januari 2012 @ 15:59:
Wat ik zou doen is het php script laten verbinden met een MySQL database die bij jou thuis draait. Je moet alles wel goed hashen, zelfs als de hacker achter de data komt, heeft ie er dan nog niks aan. Md5 of sha voldoet dus niet echt, daar zijn overal rainbow-tables van te vinden.

bcrypt.php

PHP:

require_once('bcrypt.php'):
$bcrypt = new Bcrypt(13); /*met de 13 kan je spelen om het minder veilig maar sneller te laten gaan, of juist hoger maken voor meer veiligheid maar langzamer */
/*pass uit login form */
$password = mysql_real_escape_string($_POST['password']); 
/*pass uit database */
$hash = $data['hash'];
$verify = $bcrypt->verify($password, $hash);
if($verify === true){ echo 'membercontent'; }

en register script

PHP:

require_once('bcrypt.php')
$bcrypt = new Bcrypt(13); 
$pass = mysql_real_escape_string($_POST['pass']);
$hash = $bcrypt->hash($pass);

Hashen zal ik naar aanleiding van dit topic SOWIESO gaan doen!!
Dit is dus als ik het goed begrijp om gegevens (die op wat voor manier dan ook verkregen zijn) te versleutelen zodat ALS iemand ze al te pakken krijgt niet weet wat het betekend c.q. wat er staat of bedoeld wordt.
Daar zijn we dus al met z'n allen over eens

CodeCaster schreef op donderdag 19 januari 2012 @ 16:04:

Waarom? Als je puur MySQL naar buiten opengooit, heeft men het wachtwoord of een bekende exploit nodig om in je database te komen. De kans is klein dat dat gebeurt, maar het wordt om diverse redenen (o.a. een kleine kans is alsnog een kans) afgeraden.

Sorry, dat begrijp ik even niet. Wat wordt er afgeraden?
Je zegt eigenlijk dat ik die server waar SQL op draait HELEMAAL moet dichtzetten, behalve de poort waar het SQL verkeer overheen gaat toch? Wat wordt er dan afgeraden?

Wat je dan wel kunt doen: een soort service maken in PHP, die de database gewoon aanspreekt zoals het hoort:

PHP:

function Login($user, $pass)
{
    $user = mysql_real_escape_string($user);
    $pass = mysql_real_escape_string(hash_functie($pass));
    
    $result = mysql_fetch_array(mysql_query("select userid from user where username='$user' and password='$pass'");
    
    return $result['userid'];
}

Zo is in de eerste plaats je database niet meer direct benaderbaar, en in de tweede plaats is het via deze functie onmogelijk om je database leeg te trekken. Dit is overigens geen best-practice-PHP, er zit nul error checking in en prepared statements zijn ook wel fijn.

Deze service roep je dan aan vanaf je website.

Oke, duidelijk. Wordt (morgen) naar gekeken!!

Ik kan niet begrijpen dat je heil ziet in één stap níet via TCP/IP te doen terwijl de hele keten die daaraan voorafgaat dat wel doet. Dat haalt netto dus niets uit.

Nouja, dat had ik in eerste instantie bedacht om die (zeer belangrijke) SQL database te beschermen tegen leeggooien en/of dumpen. Via serieel is dat niet 1, 2 ,3 mogelijk.

Behalve als deze twee executables de queries alsnog controleren, escapen en wat dies meer zij, maar dat kun je zonder zo veel gedoe net zo goed met een regeltje PHP-code doen, je voegt onnodig veel afhankelijkheden en moeilijkheden toe, die uiteindelijk niets toevoegen.

Klopt, dat kan in PHP inderdaad ook. Als er dan straks toch gekozen wordt om alles via TCP/IP te doen, dan zal ik dit zeker ook op deze manier gaan doen. Het maakt niet uit of het een beetje trager erdoor wordt, het moet gewoon SUPER veilig zijn.

Een firewall maakt het niet automatisch veiliger, zeker niet als je doodleuk de poort in kwestie weer opengooit in die firewall.

True.
Maar het is dus zo dat er al een exploit moet zijn als ik alleen de poort voor SQL open zet en de rest dicht timmer begrijp ik...

kwaakvaak_v2 schreef op donderdag 19 januari 2012 @ 16:07:
tja... ik vind persoonlijk dat je erg moeilijk doet om niet te hoeven hashen, of te beveiligen. Tegen elk van je argumentent is met gemak een tegen argument te bedenken waarmee je beveiliging onderuit getrokken wordt.

Begrijp me niet verkeerd, ik wil juist ALLES eraan doen om het te beveiligen. Ik zal dus ook zéker gaan hashen. Ook zal er op allerlei andere manieren gezocht worden naar betere beveiliging. Zoals hierboven al aangegeven: al wordt alles er iets trager door: no problem: het moet super safe zijn!!

Als een hacker de moeite genomen heeft om op je systeem in te breken, dan gaat ie ook wel de moeite nemen om te zien waar php de data naar toe stuurt. En ik gok dat het windows is, waarschijnlijk dot.net. Beetje decompileren en analyze van wat je .exe doet en tada... Daar gaat je Berlijnse seriele muur.

Berlijnse seriële muur
Maar er zit zeker wat in ja!!
Ook hierover gaan we de komende dagen dus goed nadenken!!

RobIII schreef op donderdag 19 januari 2012 @ 16:17:
Holy shit; dit is echt voor voer voor thedailywtf.com, met alle respect.
Ik kan hier maar 1 tip geven: doe 't gewoon op de 'gangbare' manier (en dan wel de goeie* manier); die Rube-goldberg methode die je nu aan 't fröbelen bent maakt 't geenszins veiliger en waarschijnlijk alleen maar on-veiliger danwel instabieler

Het is dat ik druk ben op 't moment, maar er zitten zó veel (potentiële) problemen in deze constructie dat je alleen maar vérder van huis bent dan wanneer je het doet zoals de rest van de wereld 't doet. En dat leer je door gewoon eens een goede tutorial door te nemen op verschillende vlakken; PHP, MySQL (of eender welk RDBMS), wat netwerk beheer/beveiliging etc.

* = Hashen, salten, correct escapen danwel parameterized queries gebruiken etc.

Tevens even een title-fix:
HTML / PHP - gebruikersnaam + wachtwoord versturen naar serv >> [PHP] Logingegevens controleren bij externe server

offtopic:
En dat is dan post 30.000 die ik hier maak

Thanks voor de title-fix, daar ging inderdaad wat verkeerd mee.
En natuurlijk feli met je 30.000ste post
Ik ga al deze posts van jullie zeer serieus nemen, en bespreken met ons team.
Blijkt toch dat e.e.a. op andere/betere manieren kan.

Janoz schreef op donderdag 19 januari 2012 @ 16:35:
Trouwens.... Je weet dat je op je Ziggo webspace helemaal geen php kunt draaien toch? (Zal voor UPC waarschijnlijk niet heel anders zijn) Er is dus waarschijnlijk helemaal geen mogelijkheid om op die plek wat serverside dingen af te handelen.

Ben ik me van bewust. Het zal ook zeker geen Ziggo of UPC worden, daar is het veel te belangrijk voor (ik ga niet voor niets denken aan serial ports etc.. puur om de data te beveiligen). Het was meer om een idee te geven hoe ik het zou willen hebben. Uiteindelijk wordt er een host gekozen die misschien bijna even goed is als de servers waar GoT op draait. (nog altijd TRUE zie ik net onderaan de pagina )

[TheNephilim]

Het is me nog niet duidelijk wat je precies wil doen, maar je gedachtegang wat betreft beveiliging is wel bijzonder. Ik bedoel, seriële verbinding, hoe kom je er op?

Ik zou gewoon de efficiëntste manier kiezen en dat top-notch beveiligen. Als ik het goed begrijp wil je via server B inloggen omdat je niet meteen op server A in wil loggen. Gewoon de kortste weg kiezen en die goed dichttimmeren, is ook veel leerzamer.

[Janoz]

Wanneer ik een "DROP DATABASE" commando weet te laten uitvoeren maakt het natuurlijk geen kont meer uit of serverside applicatie via een tcp-ip verbinding, of via een seriële verbinding loopt.

[Atmoz]

TheNephilim schreef op donderdag 19 januari 2012 @ 17:03:
Het is me nog niet duidelijk wat je precies wil doen, maar je gedachtegang wat betreft beveiliging is wel bijzonder. Ik bedoel, seriële verbinding, hoe kom je er op?

Nou, daar werk ik met mijn hobby ook veel mee (microcontrollers, home automation, remote control, etc...)
Juist omdat het zo "speciaal" is dacht ik van "daar zal een gemiddelde hacker wel niet zo 1, 2, 3, op komen"

En ALS hij er dan al achter is dat ik data via RS232 ophaal, dan moet er nog maar net uitgevogeld worden op welke manier, etc...

Ik zou gewoon de efficiëntste manier kiezen en dat top-notch beveiligen. Als ik het goed begrijp wil je via server B inloggen omdat je niet meteen op server A in wil loggen. Gewoon de kortste weg kiezen en die goed dichttimmeren, is ook veel leerzamer.

Yes, dat blijkt inderdaad wel uit dit topic

Janoz schreef op donderdag 19 januari 2012 @ 17:10:
Wanneer ik een "DROP DATABASE" commando weet te laten uitvoeren maakt het natuurlijk geen kont meer uit of serverside applicatie via een tcp-ip verbinding, of via een seriële verbinding loopt.

HOE laat jij een "DROP DATABASE" commando uitvoeren op een PC waar jij niet op kan via TCP/IP?
Dat is mijns inziens helemaal niet mogelijk. Je kunt geen commando's runnen via RS232, net zoals je bijvoorbeeld de harddisk niet kunt formatteren via RS232. Dat zou je wél kunnen als je via TCP/IP komt ingelogd op de desbetreffende computer.

Daarom heb ik (eigenlijk we, maar op aanraden van mij) die keuze in eerste instantie gemaakt.

Ik heb in dit topic nog altijd niet gelezen dat het WEL mogelijk is om ernstige dingen te doen met de database als ik werk via serieel... (dat is dus positief om te lezen!!) Want als zelfs het Pentagon gehackt kan worden, dan kan in feite alles ter wereld gehackt worden. En dat is juist wat wij niet willen. Er zullen straks zeker partijen gaan komen die ons willen hacken om ons bedrijf plat te gooien.

Hoe goed ik het ook zal beveiligen via TCP/IP, er zal ALTIJD een kans zijn dat het gehackt wordt. Er is immers 24/7 een fysieke TCP/IP verbinding aanwezig waar iedereen op zijn gemak aan kan gaan klooien.

Wordt deze kans niet kleiner als ik werk via serieel? Ik ben (nog altijd) van mening dat dit wel zo is. En met behulp van dit topic ben ik alleen maar wijzer geworden om andere dingen (communicatie tussen externe host, en thuis server (ik noem het maar steeds thuis server, maar in feite is het natuurlijk een professionele bedrijfsserver)) ook heel goed te beveiligen...

Dus eigenlijk ben ik van plan om al jullie tips met betrekking tot beveiliging, hashen, escapen, etc, etc te gaan uitvoeren EN daar bovenop ook nog eens mijn ideetje met RS232 communication... "Best of both worlds" zeg maar

[Patriot]

Op die manier komt er alleen maar een string van 8 chars (enkel a t/m z chars, dus geen "=" tekens bijvoorbeeld)

Aaahhhhh! Door mensen zoals jij klagen websites over mijn wachtwoorden! Waarom zou je er in hemelsnaam voor kiezen om mensen zo te beperken in de karakters waar ze uit mogen kiezen..

edit:
verkeerde persoon

[ Voor 49% gewijzigd door Patriot op 19-01-2012 18:24 ]

[RobIII]

atmoz schreef op donderdag 19 januari 2012 @ 18:02:
HOE laat jij een "DROP DATABASE" commando uitvoeren op een PC waar jij niet op kan via TCP/IP?

Door, bijvoorbeeld, gewoon exact dezelfde weg te bewandelen als iemand die inlogt (en me dus helemaal niet druk te maken over allerlei tamtam, rs232 oplossingen enz. die je mogelijk gebruikt).

Zolang je, in dit voorbeeld, niet bekend bent met 't concept SQL injection (en dus ook de vele andere mogelijke manieren om bepaalde zaken te manipuleren, omzeilen, breken, whatnot) moet je al helemaal niet aan de gang gaan met "seriële verbindingen" en weet-ik-het. Dacht je nou echt dat je, groen als je bent*, de rest van de wereld te slim af bent? Mensen die al jaren zo niet decennia lang al in 't vak zitten te kunnen outsmarten?

*en dat is niet erg noch een verwijt; we zijn allemaal ooit ergens begonnen

Geloof de mensen die hier zitten en weten waar ze over praten nou maar gewoon; nogmaals: dit kaartenhuis is gedoemd om in te storten, en op spectaculaire wijze

atmoz schreef op donderdag 19 januari 2012 @ 18:02:
Dus eigenlijk ben ik van plan om al jullie tips met betrekking tot beveiliging, hashen, escapen, etc, etc te gaan uitvoeren EN daar bovenop ook nog eens mijn ideetje met RS232 communication... "Best of both worlds" zeg maar

He-le-maal niet. Het enige wat je doet is een zutload aan extra lagen (lees: een hele boel extra punten die mis kunnen (en zullen) gaan) toe die uiteindelijk allemaal niets toevoegen. In het geval van SQL injection (wat maar 1 van de mogelijke -tig attack vectors is) zullen ze allemaal braaf de 'DROP DATABASE' transporteren en doorgeven totdat 't bij de database is aangekomen waarna die 't doodvrolijk uitvoert als je niet aan de juiste escaping doet/gedaan hebt. En al doe je dat, dan nog zorg je natuurlijk dat die database sowieso alleen maar wordt benaderd met credentials die uiteindelijk niet eens de rechten hebben om te droppen, deleten of whatever. Daar voegt RS232 dus niets aan toe behalve latency en een extra 'tussenstap' die kan uitvallen (= service plat, doei klanten).

[ Voor 77% gewijzigd door RobIII op 19-01-2012 19:32 ]

[CodeCaster]

atmoz schreef op donderdag 19 januari 2012 @ 18:02:
HOE

Ik heb de term "zwakste schakel" al eens laten vallen, niet?

Je RS-232-oplossing voegt net zo veel toe als iedere query die je binnenkrijgt printen in base64, in een envelop stoppen, deze in beton gieten, dit blok beton opsturen naar het hoofdkantoor, het beton laten weghakken, de envelop uitpakken, de query weer intikken, base64decode erop uitvoeren, en dan uiteindelijk de query laten uitvoeren. Op de server zelf uiteraard, via named pipes, want dan komt er geen TCP/IP aan te pas.

Dat neemt toch niet weg dat in de eerste stap, het opbouwen van de query, al een beveiligingslek kan zitten? Het zal een hacker een worst wezen hoe jij de query verpakt, hij komt uiteindelijk bij de databaseserver uit. Escaping is het keyword hier, en al het overige wat je noemt is volstrekt overbodige onzin omdat het niets toevoegt! Ja, latency misschien, maar het wordt er niet veiliger door.

Ik snap gewoon niet waar je angst voor TCP/IP vandaan komt. Onbegrip wellicht. Als het een hacker al lukt om de initiële query aan te passen, is alle overige beveiliging overbodig. Behalve als je goed escapet.

[ Voor 29% gewijzigd door CodeCaster op 19-01-2012 19:07 ]

[Atmoz]

Patriot schreef op donderdag 19 januari 2012 @ 18:22:
[...]

Aaahhhhh! Door mensen zoals jij klagen websites over mijn wachtwoorden! Waarom zou je er in hemelsnaam voor kiezen om mensen zo te beperken in de karakters waar ze uit mogen kiezen..

edit:
verkeerde persoon

Het boeit mij niets dat websites klagen over jou wachtwoorden
Ik leg toch netjes uit waarom ik daar (eventueel) voor zou kiezen?!
Dat zou ik doen om eventuele SQL injections te verkomen.
Als je een wachtwoord kiest met een bepaalde lengte en een beperkt soort karakters dan voorkom je op die manier heel makkelijk SQL injections. Toch?

RobIII schreef op donderdag 19 januari 2012 @ 18:32:
[...]

Door, bijvoorbeeld, gewoon exact dezelfde weg te bewandelen als iemand die inlogt (en me dus helemaal niet druk te maken over allerlei tamtam, rs232 oplossingen enz. die je mogelijk gebruikt).

Dat heeft toch geen nut. Alleen mijn executables (op de "thuis server" en op de SQL server ernaast) mogen/kunnen een BEPERKT aantal SQL query's doen. Dan kan diegene inloggen wat die wilt, maar er zullen alleen DIE query's gedaan worden die ik van te voren heb geprogrammeerd.

Zolang je, in dit voorbeeld, niet bekend bent met 't concept SQL injection (en dus ook de vele andere mogelijke manieren om bepaalde zaken te manipuleren, omzeilen, breken, whatnot) moet je al helemaal niet aan de gang gaan met "seriële verbindingen" en weet-ik-het.

Ik ben bekend met SQL injection. Daar hebben we het eerder in dit topic al over gehad, alleen hebben we het beestje toen een andere naam gegeven...

Dacht je nou echt dat je, groen als je bent*, de rest van de wereld te slim af bent? Mensen die al jaren zo niet decennia lang al in 't vak zitten te kunnen outsmarten?

Het zou niet de eerste keer zijn

*en dat is niet erg noch een verwijt; we zijn allemaal ooit ergens begonnen

Geloof de mensen die hier zitten en weten waar ze over praten nou maar gewoon; nogmaals: dit kaartenhuis is gedoemd om in te storten, en op spectaculaire wijze

Het is duidelijk dat de meerderheid hier in dit topic daar zo over denkt.
Ik probeer alleen te achterhalen waarom. En verder probeer ik natuurlijk de aller veiligste oplossing voor ons bedrijf te vinden.

He-le-maal niet. Het enige wat je doet is een zutload aan extra lagen (lees: een hele boel extra punten die mis kunnen (en zullen) gaan) toe die uiteindelijk allemaal niets toevoegen. In het geval van SQL injection (wat maar 1 van de mogelijke -tig attack vectors is) zullen ze allemaal braaf de 'DROP DATABASE' transporteren en doorgeven totdat 't bij de database is aangekomen waarna die 't doodvrolijk uitvoert

In mijn executable zorg ik er natuurlijk voor dat er geen enkele manier van SQL injection KAN en ZAL plaatsvinden... Ik had gehoopt dat dit onderhand al duidelijk zou zijn.

als je niet aan de juiste escaping doet/gedaan hebt. En al doe je dat, dan nog zorg je natuurlijk dat die database sowieso alleen maar wordt benaderd met credentials die uiteindelijk niet eens de rechten hebben om te droppen, deleten of whatever. Daar voegt RS232 dus niets aan toe behalve latency en een extra 'tussenstap' die kan uitvallen (= service plat, doei klanten).

RS232 zorgt ervoor dat er ALLEEN data heen/weer wordt gestuurd waarvan ik (in mijn 2 executables) bepaal of dat mag of niet. Dat mag toch ook wel duidelijk zijn onderhand. Als er alleen al het woordje "DROP" of "DELETE" of "INSERT" in de Gebruikersnaam of Wachtwoord string staat, wordt het al afgekapt. (betekend natuurlijk wel dat wachtwoorden/gebruikersnamen met deze strings erin ook niet mogen )

En zoals aangegeven: latency boeit 0,0
Het gaat er puur om dat we richting de 100% veiligheid gaan.
Al duurt een SQL query 1 hele seconde. Ik heb toch nog nergens aangegeven waarvoor het uiteindelijk allemaal dient? Jullie denken volgens mij iets teveel in hokjes. "oh, dat zal wel daar of daarvoor zijn"
Maar zo werkt dat bij ons niet!

Ik vraag gewoon om hulp, en om iets mee te denken met mijn/ons idee.
Natuurlijk ben ik ook blij die hier te krijgen, maar het mag wel wat meer "out of the box" denkend hoor...

Leg alles wat je op school hebt geleerd naast je neer, en probeer iets nieuws te verzinnen zodat het nog beter wordt!

CodeCaster schreef op donderdag 19 januari 2012 @ 18:52:
[...]

Ik heb de term "zwakste schakel" al eens laten vallen, niet?

Je RS-232-oplossing voegt net zo veel toe als iedere query die je binnenkrijgt printen in base64, in een envelop stoppen, deze in beton gieten, dit blok beton opsturen naar het hoofdkantoor, het beton laten weghakken, de envelop uitpakken, de query weer intikken, base64decode erop uitvoeren, en dan uiteindelijk de query laten uitvoeren. Op de server zelf uiteraard, via named pipes, want dan komt er geen TCP/IP aan te pas.

Dat noem ik nu "out of the box" denken. Dat is bijna exact wat ik bedoel. Dit soort idee (nouja, dan niet ZO lomp) is wel waar we heen willen. Klinkt wellicht stom voor sommige (iedereen hier?) maar ik zie zoiets wel zitten.

Dat neemt toch niet weg dat in de eerste stap, het opbouwen van de query, al een beveiligingslek kan zitten?

Heb je helemaal gelijk in. Daarom moet ook DAAR zéker naar gekeken worden!!

Het zal een hacker een worst wezen hoe jij de query verpakt, hij komt uiteindelijk bij de databaseserver uit. Escaping is het keyword hier, en al het overige wat je noemt is volstrekt overbodige onzin omdat het niets toevoegt! Ja, latency misschien, maar het wordt er niet veiliger door.

Escaping (dus tegen SQL injections) is (zeker na dit topic!!) uiteraard iets wat we zorgvuldig gaan toepassen.

MAAR: dat neemt toch niet weg dat als ik alles via TCP/IP doe, dat de server met al die belangrijke gegevens 24/7 online staat om gehackt te worden?! Als een hacker het IP adres van de thuisserver weet, en het lukt hem vervolgens om daar "Remote Desktop" of "LogMeIn" op te installeren, om vervolgens gewoon met een kleine database-tool de SQL server in het netwerk (wat volgens jullie gewoon met ethernet kabel aan moet worden gesloten) weet te vinden, dan kun je je wel voorstellen wat er gebeurt...

Ik snap gewoon niet waar je angst voor TCP/IP vandaan komt. Onbegrip wellicht. Als het een hacker al lukt om de initiële query aan te passen, is alle overige beveiliging overbodig. Behalve als je goed escapet.

De "angst" voor TCP/IP komt vanwege het feit dat zelfs de best beveiligde bedrijven/instanties via TCP/IP gehackt worden. Wij zijn dadelijk een bedrijf waar het best zinvol is om te hacken. Uiteraard ga ik hier verder niets meer over vertellen, maar dat kun je van mij aannemen.

Ik snap nog altijd niet dat juist Tweakers, die normaal gesproken met allerlei fantastische, non-standaard, ultra-leet oplossingen komen hier dan juist weer enorm tegen zijn. Volgens mij komt dat alleen omdat er op dit gebied niet genoeg "out of the box" kan worden gedacht.

No effence, ik heb absoluut veel aan de tips omtrent hashen, escapen en dat soort dingen. Maar waarom men hier zo hard roept waarom die RS232 niets toevoegt? Begrijp me niet verkeerd, ik probeer het al een aantal uur te begrijpen, maar het lukt me gewoon niet. Dat is toch zo veilig als maar kan zijn?? Hoe vaak wordt een database leeg getrokken zodat de bedrijfs (of nog erger de klant) gegevens op straat liggen? Dat zal hier niet gebeuren!

Desnoods moet ik er nog een microcontroller tussen zetten die e.e.a. in de gaten houd, en mij dan smst of belt als er iets mis gaat (teveel data in één keer uit de database gehaald of whatever) zodat ik van waar ook ter wereld de verbinding fysiek kan uitschakelen (een motortje met hefboom trek gewoon de stekker eruit)

Ook hier weer juist fijn dat er latency is (ik ga er zelfs voor zorgen dat er maar een bepaald aantal transacties per minuut mag plaatsvinden). Als ik dan niet binnen een uur kan reageren omdat ik bijvoorbeeld ergens een pint aan het drinken ben, dan kan er maximaal een bepaald aantal records uit de DB worden gehaald. Het is nogal een verschil als er 20 klantgegevens op straat liggen of 100.000... Simpel zat lijkt me toch?!


Hopelijk is mijn visie en bedoeling nu nog meer duidelijk...

Nogmaals: sowieso iedereen super bedankt voor de tips waar ik wél van kan begrijpen waarvoor het goed of fout is!!

[RobIII]

Wat jij moet doen, en dat meen ik serieus, is het volgende: jij moet heel dat idee lekker opzij zetten en gebruiken voor een proof-of-concept of hobbyproject waat je lekker mee aan de slag gaat. Als de beveiliging zo belangrijk is voor je bedrijf (en geloof me, je bent echt niet de enige instantie die denkt dat "hun" project veiliger is/moet dan de rest) dan moet je dat uitbesteden aan een gerenommeerde club die daar goed in is. Met alle respect, en dat blijf ik herhalen want ik meen 't wel, je laat in dit topic érg duidelijk merken dat je werkelijk de ballen verstand hebt van waar je mee bezig bent en gaat. Ik zeg dat niet om je te beledigen maar om je met de neus op de feiten te drukken. Dit soort zaken leer je niet 'gaandeweg' of 'tussen de soep en de aardappelen door' of 'in een weekje/maandje'.

Het komt "in het veld" om de haverklap voor dat er weer een "slimmerik" is geweest die bedacht had dat zijn/haar 'encryptiemethode' veiliger was dan de rest van de "open", "bekende" encryptiestandaarden die al sinds jaar-en-dag zichzelf staande weten houden tegen alles wat men er tegenaan kan smijten. En met diezelfde regelmaat gaan die lui, stuk voor stuk, geen één uitgezonderd, uiteindelijk gruwelijk op hun bek omdat blijkt dat hun 'encryptiemethode' zo lek als een mandje is.

Nu besteed ik een alinea aan 'encryptie' maar dat had ook over 'sql injections', 'firewalls', 'routering', 'authenticatie' en noem-maar-op kunnen zijn. Je bent, nogmaals met alle respect, gewoon way, waaaaay te groen. Dat straalt van dit topic af. En nogmaals, dat is geen belediging aan je adres maar een constatering en iets wat we allemaal ooit zijn geweest (of nog zijn). Ik ben ook geen 'security expert', don't get me wrong, maar ik weet wél dat je nu helemaal op 't verkeerde been "out of the box" aan 't denken bent en ik weet ook dat er maar 1 degelijk advies is waar je iets mee kunt: droppen en uitbesteden. Als het écht zo belangrijk is als je aangeeft dan wil je hier je billen niet aan branden.

Ik hoop van harte dat je dit ter harte neemt, want het is met alle goede intenties van de wereld geschreven.

[ Voor 6% gewijzigd door RobIII op 19-01-2012 21:51 ]

[Gomez12]

Echt geschikt voor thedailywtf.

Laat ik heel simpel proberen te vertellen waarom RS-232 niets toevoegt : Het is enkel een transportlaag en daarmee equivalent aan tcp/ip (ook een transportlaag enkel tig keer zo snel en tig keer betere tools om onregelmatigheden te bespeuren).

Jouw hele concept van server-client etc. etc. kan je perfect 100% gelijkwaardig (enkel beter) uitvoeren over tcp-ip. Stel simpelweg je sql-server-os in dat die enkel maar tcp-ip connecties accepteert op 1 poort (waar jouw client progje op draait die dan de sql-server benadert). Et voila, iemand die met logmein je inet-server overneemt kan nog steeds enkel met je db-server praten via jouw progje / encryptie en kan nog steeds geen databases droppen etc.

Transportlagen worden niet gehackt, het zijn altijd de applicaties die gehackt worden. En tja, als je het hele idee van transportlagen al niet begrijpt (of hashing of sql-injections of ... ) dan heb ik nou niet echt zo'n hoge verwachting van jouw "onhackbare" client-server progje. Voor een transportlaag hoef je dus ook niet out of the box te denken, het gaat om de data die erover vervoert wordt, de transportlaag is niet relevant (enkel bij serieel/extreem langzame transportlagen is het dan een uitzondering omdat die zo geDOS't worden. Als ik via een 100Mb pijp allemaal logins op jouw php-script afvuur dan kan jij de eerstkomende paar uur geen klanten meer bedienen, heeft niets met je php-script te maken, heeft niets met je server/client te maken is puur en alleen maar je seriele connectie die ervoor zorgt dat je jezelf DOS't)

Sowieso nog een tip qua client-server coding. Leg aan de client geen limieten op (dus programmeer daar niet de query's in). Leg je limieten enkel aan de server op (wat die begrijpt), anders wordt het een giga-warboel. Dan vergeet je ergens iets toe te voegen, of je vergeet ergens iets weg te halen. Je wilt simpelweg maar 1 code-base hebben die je kan controleren, niet 2 die je kan copy-pasten.

[TheNephilim]

atmoz schreef op donderdag 19 januari 2012 @ 21:14:

[...]

Dat heeft toch geen nut. Alleen mijn executables (op de "thuis server" en op de SQL server ernaast) mogen/kunnen een BEPERKT aantal SQL query's doen. Dan kan diegene inloggen wat die wilt, maar er zullen alleen DIE query's gedaan worden die ik van te voren heb geprogrammeerd.


[...]

Maar hoe log je dan in?

Normaal check je de gegevens in de database (dus gaat er een string van invoerveld naar de SQL server, dus kun je iets naar de SQL server sturen).

Wat ook kan is de inloggegevens checken in PHP, maar dan duiken er weer andere problemen op. Je gaat vast deze laatste mogelijkheid uitvoeren, anders kun je nog steeds vanaf buiten bij de SQL server.

[Gomez12]

TheNephilim schreef op vrijdag 20 januari 2012 @ 10:26:
[...]
Maar hoe log je dan in?

Normaal check je de gegevens in de database (dus gaat er een string van invoerveld naar de SQL server, dus kun je iets naar de SQL server sturen).

Als ik het goed begrijp wil hij een heel beperkte set van sql-query's gaan coderen en verwacht hij daar beveiliging uit te halen.

Dus web-site stuurt naar inet-inhouse-server bijv :select * from users where id=1
en de inet-inhouse-server leest dit en stuurt dan over de seriele poort door : a1
De sql-inhouse-server weet dan dat a staat voor : select * from users where id=... en bouwt die query weer op en stuurt hem naar sql-server, deze voert hem uit en het antwoord wordt weer via de coderingen teruggestuurd naar web-site..

Zolang a alleen maar staat voor : select * from users where id=... kan er niets anders uitgevoerd worden, de inet-inhouse-server doet namelijk niets met andere query's.
Dat je hetzelfde kan bereiken met stored procedures en daar rechten op geven, tja dat is blijkbaar te veel binnen the box gedacht.

[CH4OS]

Ik zou met dit soort systemen ook zeker kijken naar een challenge & response systeem, om misbruik van logingegevens te voorkomen. En uiteraard een secured protocol (zoals HTTPS) gebruiken voor het versturen van die gegevens.

[ Voor 26% gewijzigd door CH4OS op 20-01-2012 15:18 ]

[Gomez12]

CptChaos schreef op vrijdag 20 januari 2012 @ 15:17:
Ik zou met dit soort systemen ook zeker kijken naar een challenge & response systeem, om misbruik van logingegevens te voorkomen. En uiteraard een secured protocol (zoals HTTPS) gebruiken voor het versturen van die gegevens.

Ach, ik zou als ik TS was (en ik hoop dat TS het ook gaat laten vallen) het laten vallen.

TS heeft wat klepels horen luiden, maar heeft geen idee waar de klok hangt. Dan kan je nog wel meer klepels gaan aanbieden, maar zonder klok heeft TS er niets aan. En die klok moet van scratch worden opgebouwd bij TS.

De hele denkwijze is momenteel gewoon fout (bijv. RS-232) en falen heeft de TS ook nog nooit van gehoord (uiteraard wordt zijn client-server zelfbouwcode 100% sql-injection free, hij wist in het begin van het topic nog niet eens dat hij het moest doen magoe, 100% sql-injection free code is 10 minuten werk oid)
Nog even daargelaten dat het eerst niet pentagon-level security hoeft te zijn en op het laatst moet het wel richting 100% veilig gaan.

Als dit project in de eerstkomende 10 jaar live moet gaan dan voorzie ik al problemen met de 1e security check (onderhoudbarheid nog even daargelaten). TS snapt gewoon niet de basisprincipes, dan kan je wel woordjes aan hem voeren die hij op phpscripts.nl kan zoeken en copy-pasten maar of je dat nu echt helpen kunt noemen?

[OkkE]

Gomez12 schreef op vrijdag 20 januari 2012 @ 16:14:
TS heeft wat klepels horen luiden, maar heeft geen idee waar de klok hangt. Dan kan je nog wel meer klepels gaan aanbieden, maar zonder klok heeft TS er niets aan. En die klok moet van scratch worden opgebouwd bij TS.

Hoe meer je van een onderwerp weet, hoe duidelijker het wordt dat je er eigenlijk nog bijna niks van weet.

(uiteraard wordt zijn client-server zelfbouwcode 100% sql-injection free, hij wist in het begin van het topic nog niet eens dat hij het moest doen magoe, 100% sql-injection free code is 10 minuten werk oid)

Als je alleen een X aantal "SELECT" queries hard in je code zet (zonder user input) en afhankelijk van een if(var===int) uitvoert, moet het wel aardig SQL Injection vrij te krijgen zijn.

---

Ik ben erg benieuwd hoe dit gaat aflopen.

[Gomez12]

OkkE schreef op vrijdag 20 januari 2012 @ 16:55:
[...]
Als je alleen een X aantal "SELECT" queries hard in je code zet (zonder user input) en afhankelijk van een if(var===int) uitvoert, moet het wel aardig SQL Injection vrij te krijgen zijn.

Vast wel, voor een maand oid. Daarna komt het geknoei dat er query's moeten toegevoegd worden (aan 2 kanten) dat er query's veranderd moeten worden etc. etc. Of de dbase veranderd vanwege x of y.

Het is een shitload aan foutgevoelige werkzaamheden die je hiermee introduceert met een upgradebalitiy van nul, een onderhoudbaarheid van ook ergens nul en een meerwaarde boven bestaande technieken van onder nul.
Maar je hebt het wel zelf gemaakt dan, je hebt in ieder geval niet iemand anders zijn best-practices gevolgd