Posts by FangorN

Euh, als je testbetalingen probeert te doen vanaf een lokaal domein dan gaat dat sowieso niet werken he :). De website waar de payment service provider (PSP) een respons naartoe moet sturen moet bereikbaar zijn via het internet.

Welke foutmeldingen krijg je waaruit blijkt dat de query mislukt (of krijg je deze niet)? Heb je de query al een keer gedumpt?

Enne:
- zou je de acties niet opdelen in aparte delen? in plaats van zo'n complex if-elseif-elseif-else statement? ik heb daar net een artikeltje over geschreven
- hoe is een aanroep van ?page=kopen&id=1&p=success&... precies beveiligd?

Ik luister op dit moment naar de top2000

Ik zou mij hier verder niet zo druk om maken, te meer omdat dit niet in je "cirkel van invloed" zit - het is de verantwoordelijkheid van de eindgebruiker zelf dat deze zijn/haar gegevens niet kwijtraken.

Je kunt hooguit een reset-functionaliteit faciliteren, voor de rest zoeken ze het maar uit :].

Huh?

Potentiële aanvallers ontvangen toch sowieso geen correspondentie-mail?

Waar ik je gebruikers voor zou beschermen is:
- een password reset die niet door de gebruiker zelf is ingezet, dit kun je makkelijk bereiken door een tussenstap in te bouwen die gebruik maakt van een unieke bevestigings-link
- dat gebruikers gespamd worden door bovenstaande berichten, dit kun je bereiken door een status bij te houden die controleert of er al een reset-verzoek loopt, mogelijk met een timeout van een dag ofzo, zodat iemand ten hoogste één mailtje per dag ontvangt

Je kunt je reset-password functionaliteit ook zo maken dat er helemaal geen mededelingen worden gedaan over het slagen/falen van een aanvraag zodat je ook niet makkelijk kunt vissen naar "bestaande" e-mailadressen.

EDIT: dit geldt ook voor het inlogformulier, daar zou je ook geen enkele mededeling moeten doen over wat er fout is, maar simpelweg zeggen dat de login onjuist is als er onjuiste gegevens worden ingevuld.

Citaat van Victor

Het netwerk stuurt constant informatie naar iedereen.

Dat lijkt mij toch zoiets als security through obscurity?

Ook is dit niet heel erg makkelijk schaalbaar?

Heb je ook een bronvermelding naar artikelen / uitleg over het principe?

Ai.

Wellicht gebruikten ze een invariabele seed voor hun random number generator? De nummers zijn dan herproduceerbaar. "Random" numbers zijn niet geheel random.

PHP had/heeft een soortgelijk probleem met mt_rand().

On a side note, niet echte random "random" numbers kunnen ook een probleem vormen bij het salten van wachtwoorden, "random" strings kunnen dan de zwakste schakel in je wachtwoord-functionaliteit zijn.

Ah, het kan zijn dat output buffering standaard niet aan staat bij deze host (setting "output_buffering").

Dit zou eigenlijk ook niet nodig hoeven te zijn.

Mogelijk wordt er output geproduceerd voordat er header() functies worden aangeroepen, of andere specifieke functionaliteit die geregeld moet zijn voordat je met output start (zoals sessies, die standaard van cookies gebruik maken). Het aanzetten van output buffering kan een simpele oplossing zijn, maar dat is naar mijn mening een lapmiddel.

De "headers already sent" foutmeldingen zouden ook een gevolg kunnen zijn van een andere foutmelding (die zorgt voor het produceren van output, wat weer resulteert in de daaropvolgende "headers already sent" fouten). Zorg dus ook dat je niet enkel aan symptoombestrijding doet en enkel deze (indirecte) fouten onder het tapijt schuift.

Je hebt nu wel een aanknopingspunt: staat voor regel 7 ergens een regelovergang of spatie in index.php? Dan is dat mogelijk de oorzaak.

Maakt de website gebruik van .htaccess, meestal is het zoiets.
(Ah dit was al voorgesteld)

Tevens zijn logs je vriend in deze.

En (zoals aangehaald in een ander topic) is een testomgeving ook handig :).

Werkt een losstaand PHP script wel? Vraag daarin eens je PHP informatie op met phpinfo().

Als je je fout niet uit logs kunt herleiden zul je dit stapsgewijs moeten gaan debuggen.

EDIT: wellicht staat short_open_tag uit en gebruik je overal <? ... ?> en <?= ... ?>? Het kan echt van alles zijn.

Een wit scherm kan ook duiden op teveel geheugenconsumptie, maar dat treedt eerder op bij (zware) bewerkingen met geuploade afbeeldingen, niet zozeer met het simpelweg laden van een website.

En je zou eens kunnen kijken middels phpinfo() of er lijpe extensies in zitten zoals suhosin ofzo.

Maar waarom zou je bestanden willen openen vanuit FileZilla? Edit je dan on-the-fly bestanden die meteen weer geupload worden? Kun je dan niet beter een testomgeving opzetten ofzo?

Citaat van MiCa-

Jullie moeten mij niet de les spellen i.v.m. PDO of MySQLI want ik ben de persoon die ervoor gezorgd heeft dat ons bedrijf vanaf 2013 PDO gaat gebruiken voor alle projecten sinds dien..

Gebruik je naast MySQL ook andere database typen dan (EDIT: en in hoeveel gevallen)?

Citaat van MiCa-

Ik weet donders goed dat die functies niet deprecated zijn zolang wij zelf kiezen welke PHP versie we gebruiken

Maar met nieuwere versies komen er ook bug- en security fixes, verbeterde performance en andere/nieuwe functionaliteit. Daarnaast moet je ook de hard- en software (EDIT: van de webserver zelf) in beschouwing nemen waar soortgelijke overwegingen (met name ten aanzien van security) spelen. Als je zelf dedicated servers beheert dan heb je deze vrijheid, maar de vraag is of je je dat op langere tijd kunt veroorloven.

Citaat van MiCa-

Ook zitten we met ons bedrijf met meer dan 300 websites van de 400 die nog oude mysql functies gebruiken.

Citaat van MiCa-

Zou jij het zien zitten al die websites om te bouwen?
Wij dus ook niet

Dit (legacy) probleem (als je het zo kunt noemen) gaat niet vanzelf weg en wordt over tijd alleen maar "groter". De eerste stap om langzaam naar een oplossing toe te werken is allereerst ruimte creëren om dit onderwerp bespreekbaar te maken, binnen de organisatie maar ook daarbuiten. Vaak zijn klanten zich niet bewust (of willen niet begrijpen) dat software een beperkte houdbaarheidsdatum heeft. Je zult dus ook moeten werken aan het creëren van begrip bij klanten dat code onderhouden moet worden, dat hier tijd in gaat zitten en (dus) dat dit geld gaat kosten. Dit valt onder verwachtingsmanangement als je het mij vraagt.

Het klinkt niet alsof je hier actief mee bezig bent maar misschien is het verstandig om hier eens een balletje over op te gooien want when smelly substances hit a rotating object (oftewel, er komt een moment dat je niet meer over kan maar over moet en als je dan geen plan hebt) dan heb je ECHT een probleem.

En uit een eerdere post:

Citaat van MiCa-

Overigens zie ik nog heel veel projecten (waar ik help of verbeter) die de oude mysql fncties gebruiken, en ik denk niet dat al die projecten de enige zijn op het web..

Mja, maar dat is dus in zekere zin een ontwerpfout. Je hebt alle mysql_-functies waarschijnlijk hard in je code staan. Stel nu dat je hier een of meer wrapper classes voor had geschreven (of zelfs wrapper functies). Het omschakelen naar MySQLi was dan in zijn simpelste vorm een kwestie van het aanpassen van de implementatie van je wrapper classes geweest. Dan hoefde je in elk project -in het eenvoudigste geval- slechts enkele regels code te vervangen in plaats van een search-replace door je hele codebase te doen (met toevoegingen van een database-link-parameter).

Als je slim bent doe je dit nu voor oplossingen met MySQLi (of zelfs PDO) alsnog zodat je niet rechtstreeks (API-specifieke) database-functies aanroept. Een ezel stoot zich in het algemeen...

Tevens: deze thread is enigszins offtopic geraakt, moderators, doe jullie werk.

Citaat van MiCa-

Hoeft niet beveiligd te worden..

Uhm, dat staat niet op voorhand vast. Indien de getoonde informatie na aanroep van die link niet voor iedereen is bedoeld zul je wel degelijk enige controles in moeten bouwen...

Citaat van MiCa-

Enige wat je moet beveiligen is je server side code, daar moet je dus volgende paramater: ?online= Netjes gaan escapen indien je a.h.v. deze paramater een database interactie doet.

Ook dit is niet helemaal volledig. Ten eerste zou je je input moeten filteren, als $_GET['online'] niet bestaat of niet het juiste formaat heeft hoe je de query niet eens uit te voeren.

Citaat van MiCa-

Indien je standaard mysql gebruikt kan je de functie:

Indien je nog standaard mysql gebruikt moet je als de sodem... wiedeweerga overstappen op MySQLi of PDO. Zeker als je bezig bent met het schrijven van nieuwe code. Dan code schrijven die via mysql_-functies interactie heeft met je database staat bijna gelijk aan tijdsverspilling omdat deze functies al ~10 uitgerangeerd zijn en binnenkort voorgoed verdwijnen (PHP7 heeft ze niet meer geloof ik).

Ik zie geen enkele of dubbele quotes, < punthaken >, en ook geen exotische karakters zoals ë of € of ™ of wat dan ook.

Citaat van Tredgy

Gebruikt MySQL niet automatisch UTF8 codering? en anders mysqli_set_charset();

Ik denk dat je het toch anders moet zien. Het antwoord op jouw eerste vraag is waarschijnlijk "nee", vaak is de standaard character encoding nog steeds latin1. Verder lijkt het mij ook onverstandig om uit te gaan van een default, het is veel beter om deze expliciet in te stellen (bijvoorbeeld bij de creatie van de tabel en bij het maken van een connectie).

Dan misschien handig voor de beeldvorming wat een set_charset() functie doet. Dit moet je zien al een contract tussen jouw applicatie en de database. Dit contract bevat twee bepalingen:
- jij zorgt ervoor dat alle data die je aanlevert in de overeengekomen character encoding is opgesteld
- de database zorgt ervoor (of doet in ieder geval een oprechte poging) om alle data die zij teruggeeft aan te leveren in de overeengekomen character encoding

Dit is dus de "taal" waarmee jullie met elkaar praten, maar dat zegt helemaal niets over welke character encoderingen de tabellen of de data daarin zou moeten hebben en met een set_charset() methode kun je dit ook niet afdwingen omdat dit al is vastlgelegd in de definities van de tabellen zelf.

Indien jouw website UTF-8 is en jouw database enkel latin1 tabellen bevat kun je dus nog steeds set_charset('utf8') gebruiken: als je iets opvraagt vertaalt MySQL de latin1 data naar utf8 en als je data wegschrijft vertaal MySQL de UTF-8 data naar latin1 (maar dat laatste zal mogelijk niet altijd passen).

Beschouw set_charset() dus als "de character encoding die je op jouw website wenst te gebruiken". Je moet er dan dus ook zorg voor dragen dat je, als je data wegschrijft naar een database, deze data aanlevert in de overeengekomen character encoding anders gaat het mis.

Ook Google heeft zelf al een 2-step-verification dienst wat mij nog steeds een veilige(re) methode lijkt.

De afsluiter van dat installatieproces vond ik niet zo sterk: "Your files are still where you left them" of iets dergelijks. Damn skippy they are! Het laat je een beetje in het ongwisse wat je op dat moment nog zou moeten doen. Je kunt eigenlijk alleen maar afwachten.

Geen van de bovenstaande features gebruik ik echt, maar ik heb wel het idee dat Windows iets stabieler is geworden (knocks on wood).

Enne, jQuery heeft een standaard functie genaamd serialize() waarmee je automatisch een URL-encoded string kunt bouwen.

Jouw code gebruikt een langere en omslachtigere methode, en encodeert de waarden op dit moment ook helemaal niet... Als er dus gekke tekens in je data zitten die in de URL-encoded context een speciale betekenis hebben bestaat de kans dat de data-string verkeerd wordt uitgelezen aan de ontvangstkant, met onvolledige/corrupte data als gevolg.

Ook is het altijd van belang dat al je character encoderingen in de pas lopen, vooral als je via AJAX data doorgeeft, klopt het dat al je data ook UTF-8 geëncodeerd is (en utf8 in MySQL)?

Het bovenstaande kun je eenvoudig testen door eens wat exotische karakters te voeren aan de database via een AJAX-call, met hier en daar ook karakters als &, >, < en enkele en dubbele quotes. Als alles goed wordt weergegeven na opslaan en er ook weer goed uitziet als je deze data weer wilt gaan bewerken (pas dan heb je een volledig rondje gemaakt) dan heb je je werk goed gedaan. Anders... zet je een stevige pot koffie en los je dit alsnog op :).

En waar zit enige beveiliging? Of kan iedereen dit uitvoeren?

Ik heb standaard alle cache uit staan (ontwikkelaars tsssss), maar zie niets out of the ordinary :s.