Beveiliging is een interessant concept en trekt veel mensen aan. Helaas is het een complex onderwerp en zelfs de professionals hebben het bij het verkeerde eind. Ik heb beveiligingslekken gevonden in Google (CSRF), Facebook (meer CSRF), verschillende grote online retailers (voornamelijk SQL-injection / XSS), evenals duizenden kleinere sites, zowel zakelijk als persoonlijk.
Dit zijn mijn aanbevelingen:
1) Gebruik geparametriseerde zoekopdrachten
Geparametriseerde query's dwingen de waarden die aan de query zijn doorgegeven, te worden behandeld als afzonderlijke gegevens, zodat de invoerwaarden niet door het DBMS kunnen worden geparseerd als SQL-code. Veel mensen zullen je aanraden om aan je strings te ontsnappen met mysql_real_escape_string() , maar in tegenstelling tot wat vaak wordt gedacht, is het niet een allesomvattende oplossing voor SQL-injectie. Neem deze vraag bijvoorbeeld:
SELECT * FROM users WHERE userID = $_GET['userid']
Als $_GET['userid'] is ingesteld op 1 OR 1=1 , er zijn geen speciale tekens en er wordt niet gefilterd. Dit resulteert in het retourneren van alle rijen. Of, erger nog, wat als het is ingesteld op 1 OR is_admin = 1 ?
Geparametriseerde zoekopdrachten voorkomen dat dit soort injectie plaatsvindt.
2) Valideer uw invoer
Geparametriseerde zoekopdrachten zijn geweldig, maar soms kunnen onverwachte waarden problemen met uw code veroorzaken. Zorg ervoor dat je valideert dat ze binnen bereik zijn en dat ze de huidige gebruiker niet toestaan iets te wijzigen wat hij niet zou moeten kunnen.
U kunt bijvoorbeeld een formulier voor wachtwoordwijziging hebben waarmee een POST-verzoek wordt verzonden naar een script dat hun wachtwoord wijzigt. Als u hun gebruikers-ID als een verborgen variabele in het formulier plaatst, kunnen ze deze wijzigen. Verzenden id=123 in plaats van id=321 kan betekenen dat ze het wachtwoord van iemand anders wijzigen. Zorg ervoor dat ALLES correct is gevalideerd, in termen van type, bereik en toegang.
3) Gebruik htmlspecialchars om te ontsnappen aan de weergegeven gebruikersinvoer
Stel dat uw gebruiker zijn "over mij" invoert als iets als dit:</div><script>document.alert('hello!');</script><div>
Het probleem hiermee is dat uw uitvoer markeringen bevat die de gebruiker heeft ingevoerd. Dit zelf proberen te filteren met zwarte lijsten is gewoon een slecht idee. Gebruik htmlspecialchars om de tekenreeksen uit te filteren zodat HTML-tags worden geconverteerd naar HTML-entiteiten.
4) Gebruik geen $_REQUEST
Cross-site request forgery (CSRF)-aanvallen werken door de gebruiker ertoe te brengen op een link te klikken of een URL te bezoeken die een script vertegenwoordigt dat een actie uitvoert op een site waarvoor ze zijn aangemeld. De $_REQUEST variabele is een combinatie van $_GET , $_POST en $_COOKIE , wat betekent dat u het verschil niet kunt zien tussen een variabele die is verzonden in een POST-verzoek (d.w.z. via een input tag in uw formulier) of een variabele die in uw URL is ingesteld als onderdeel van een GET (bijv. page.php?id=1 ).
Stel dat de gebruiker een privébericht naar iemand wil sturen. Ze kunnen een POST-verzoek sturen naar sendmessage.php , met to , subject en message als parameters. Laten we ons nu eens voorstellen dat iemand in plaats daarvan een GET-verzoek stuurt:
sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!
Als u $_POST . gebruikt , zult u geen van die parameters zien, omdat ze zijn ingesteld in $_GET in plaats van. Uw code ziet de $_POST['to'] . niet of een van de andere variabelen, zodat het bericht niet wordt verzonden. Als u echter $_REQUEST . gebruikt , de $_GET en $_POST aan elkaar vast komen te zitten, zodat een aanvaller die parameters kan instellen als onderdeel van de URL. Wanneer de gebruiker die URL bezoekt, wordt het bericht per ongeluk verzonden. Het meest zorgwekkende is dat de gebruiker niets hoeft te doen. Als de aanvaller een kwaadaardige pagina maakt, kan deze een iframe . bevatten die naar de URL verwijst. Voorbeeld:
<iframe src="http://yoursite.com/sendmessage.php?to=someone&subject=SPAM&message=VIAGRA!">
</iframe>
Dit resulteert erin dat de gebruiker berichten naar mensen stuurt zonder ooit te beseffen dat ze iets hebben gedaan. Om deze reden moet u $_REQUEST . vermijden en gebruik $_POST en $_GET in plaats daarvan.
5) Behandel alles wat je krijgt als verdacht (of zelfs kwaadaardig)
Je hebt geen idee wat de gebruiker je stuurt. Het kan legitiem zijn. Het kan een aanslag zijn. Vertrouw nooit iets dat een gebruiker u heeft gestuurd. Converteer naar de juiste typen, valideer de invoer, gebruik witte lijsten om te filteren waar nodig (vermijd zwarte lijsten). Dit omvat alles verzonden via $_GET , $_POST , $_COOKIE en $_FILES .
Als u zich aan deze richtlijnen houdt, heeft u een redelijke positie op het gebied van beveiliging.