PHP/SQL reinigen $ _POST, $ _GET, enz ...?

Ok, dit onderwerp is een broeinest, dat begrijp ik. Ik begrijp ook dat deze situatie afhankelijk is van wat je als code gebruikt. Ik heb drie situaties die moeten worden opgelost.

  1. Ik heb een formulier waarin we mensen toestemming moeten geven om opmerkingen en uitspraken te doen die komma's, tildes, enzovoort gebruiken ... maar toch beschermd blijven tegen aanvallen.

  2. Ik heb mensen die dit soort datums invoeren: 10/13/11 mm/dd/jj in het Engels, kan dit worden gezuiverd?

  3. Hoe begrijp ik hoe ik htmlspecialchars() , htmlentities() en real_escape_string() correct gebruik? Ik heb de php.net-site en enkele berichten hier gelezen, maar dit lijkt me een situatie waarin het allemaal afhangt van de persoon die de vraag leest, wat het juiste antwoord is.

Ik kan echt niet accepteren dat ... er moet een antwoord zijn waarin tekstformaten vergelijkbaar met die ik hier plaats kan worden gezuiverd. Ik zou graag willen weten of en hoe het mogelijk is.

Bedankt ... want het lijkt me dat wanneer ik deze vraag op andere plaatsen stel, het me ergert ... Ik leer wat ik moet weten, maar ik denk dat ik een plateau heb geraakt in wat ik kan weten zonder een voorbeeld van wat het is bedoeld om te doen ...

Bij voorbaat dank.

2
@me dubbele post, verkeerd gebied.
toegevoegd de auteur Matt Ridge, de bron
het is verbazingwekkend hoeveel tijd je besteedt aan string sanitation in webapplicaties. Ik durf te zeggen dat de overgrote meerderheid van de PHP-code die ik heb geschreven pure manipulatie van snaren was. De feitelijke 'logische' delen bleken in vergelijking.
toegevoegd de auteur Marijn van Vliet, de bron

3 antwoord

Het is een zeer belangrijke vraag en het heeft eigenlijk een eenvoudig antwoord in de vorm van coderingen. Het probleem waarmee u wordt geconfronteerd, is dat u tegelijkertijd veel talen gebruikt. Eerst ben je in HTML, vervolgens in PHP en een paar seconden later in SQL. Al deze talen hebben hun eigen syntaxisregels.

Het ding om te onthouden is: een string moet te allen tijde in de juiste codering staan.

Laten we een voorbeeld nemen. U hebt een HTML-formulier en de gebruiker voert de volgende tekenreeks in:

I really <3 dogs & cats ;')

Upon pressing the submit button, this string is being send to your PHP script. Lets assume this is done through GET. It gets appended to the URL, which has its own syntax (the & character has special meaning for instance) so we are changing languages. This means the string must be transformed into the proper URL-encoding. In this case the browser does it, but PHP also has an urlencode function for that.

In het PHP-script wordt de tekenreeks opgeslagen in $ _ GET , gecodeerd als een PHP-reeks. Zolang je PHP codeert, is dit prima. Maar laten we nu de reeks gebruiken in een SQL-query. We veranderen talen en syntaxisregels, daarom moet de string worden gecodeerd als SQL via de mysql_real_escape_string -functie.

Aan de andere kant willen we de string misschien weer teruggeven aan de gebruikers. We halen de string uit de database terug en deze wordt als een PHP-string aan ons geretourneerd. Wanneer we het in HTML willen invoegen voor uitvoer, veranderen we de talen opnieuw, dus moeten we onze tekenreeks naar HTML coderen via de functie htmlspecialchars .

Gedurende de hele weg is de string altijd in de juiste codering geweest, wat betekent dat elk teken dat de gebruiker kan bedenken, overeenkomstig zal worden behandeld. Alles moet soepel en veilig verlopen.

Een ding om te vermijden (soms wordt dit zelfs aanbevolen door de onwetende) is het vroegtijdig coderen van je string. U kunt bijvoorbeeld htmlspecialchars toepassen op de tekenreeks voordat deze in de database plaatst. Op deze manier, wanneer u de reeks later uit de database haalt, kunt u deze in de HTML plakken, geen probleem. Klinkt goed? Ja, echt geweldig totdat je support-tickets krijgt van mensen die zich afvragen waarom hun PDF-ontvangst vol zit met & amp; & gt; rommel.

In code:

form.html:

<form action="post.php" method="get">
    
    <input type="submit"/>
</form>

URL die het genereert:

http://www.example.org/form.php?comment=I%20really%20%3C3%20dogs%20&%20cats%20;')

post.php:

// Connect to database, etc....

// Place the new comment in the database
$comment = $_GET['comment'];//Comment is encoded as PHP string

// Using $comment in a SQL query, need to encode the string to SQL first!
$query = "INSERT INTO posts SET comment='". mysql_real_escape_string($comment) ."'";
mysql_query($query);

// Get list of comments from the database
$query = "SELECT comment FROM posts";

print '<html><body>

Posts

'; print '<table>'; while($post = mysql_fetch_assoc($query)) { //Going from PHP string to HTML, need to encode! print '<tr><td>'. htmlspecialchars($post['comment']) .'</td></tr>'; } print '</table>'; print '</body></html>'
10
toegevoegd
Kun je een concept laten zien van waar je het over hebt? Ook gewoon nieuwsgierig ... is er een manier om de & amp; & Gt; extras?
toegevoegd de auteur Matt Ridge, de bron
@Rodin Bedankt, je bent de eerste die dit echt een voorbeeld geeft van wat elke code feitelijk doet. Het wordt zeer op prijs gesteld. Het geeft inzicht in hoe deze correct worden gebruikt. Ik ben er zeker van dat veel andere mensen uw inspanningen ook zullen waarderen.
toegevoegd de auteur Matt Ridge, de bron
@Rodin Ik heb een vraag, je gebruikt print, het doet hetzelfde als echo correct is?
toegevoegd de auteur Matt Ridge, de bron
Als je ooit eindigt met & amp; & gt; extra's, het kan zijn dat de string twee keer is gecodeerd met htmlspecialchars . U kunt htmlspecialchars_decode gebruiken om ze te verwijderen. Maar wees heel voorzichtig wanneer je dit doet! Dit opent mogelijk de reeks opnieuw voor javascript-injectieaanvallen. Het is bijna altijd beter om te zoeken waar je ten onrechte de tweede htmlspecialchars hebt toegepast.
toegevoegd de auteur Marijn van Vliet, de bron
@MattRidge Ik vermoed dat ik zo ouderwets ben. Ik hou van het woord 'afdrukken' :)
toegevoegd de auteur Marijn van Vliet, de bron
+1 om te vermelden waarom HTML-codering voorafgaand aan het invoegen van de database een slecht idee is.
toegevoegd de auteur Justin ᚅᚔᚈᚄᚒᚔ, de bron
toegevoegd de auteur Justin ᚅᚔᚈᚄᚒᚔ, de bron

Het gaat erom dat u begrijpt wat elke ontsmettingsfunctie die voor u beschikbaar is voor is en wanneer deze moet worden gebruikt. Database-escapefuncties zijn bijvoorbeeld ontworpen om gegevens veilig in te voegen in de database en moeten als zodanig worden gebruikt; maar HTML-escapefuncties zijn ontworpen om kwaadwillende HTML-code (zoals JavaScripts) te neutraliseren en het veilig te maken om gegevens uit te voeren die uw gebruikers kunnen bekijken. Sanitize het juiste ding op het juiste moment. *

  • Er zijn twee verschillende basisbenaderingen die u kunt nemen: u kunt HTML opschonen wanneer u deze ontvangt, of u kunt deze precies opslaan zoals u deze hebt ontvangen en deze alleen opschonen wanneer het tijd is om deze naar de gebruiker uit te voeren. Elk van deze methoden heeft zijn voorstanders, maar de tweede is waarschijnlijk het minst gevoelig voor problemen (met de eerste, wat doe je als er een fout ontdekt wordt in je ontsmettingsprocedure en je merkt dat je onvoldoende ontsmette inhoud hebt opgeslagen in je database ?)

Datums kunnen worden opgeschoond met behulp van een functie voor het parseren van datums. In PHP kun je kijken naar strtotime() . Uw doel is doorgaans om een ​​tekenreeksrepresentatie van een datum op te nemen en een object uit te voeren dat een datum vertegenwoordigt, of een andere reeks die dezelfde datum op een canonieke manier weergeeft (dat wil zeggen: in een specifiek formaat).

1
toegevoegd
Ok ... Ik ben op zoek naar een verklaring in te voegen waarmee tekens zoals de verklaring die ik nu maak. Dat is alles, en dan toe te staan ​​dat deze verklaring wordt bekeken. Terwijl je wordt gedesinfecteerd.
toegevoegd de auteur Matt Ridge, de bron
Ik doe dit op één pagina, niet meervoudig als ik begrijp wat je zegt ... Ik haat het om dit te zeggen, ik heb al opgezocht wat je suggereert. Ik heb echt geen andere manier nodig om iets te doen als ik niet begrijp hoe ik de oorspronkelijke vraag in de eerste plaats goed moet doen.
toegevoegd de auteur Matt Ridge, de bron
U hebt dus twee scripts: een script die de inhoud (het bericht) ontvangt en invoegt in de database, en een die de inhoud ophaalt en weergeeft. Het eerste script verzendt gegevens naar de database, dus het moet een database-escapefunctie gebruiken om de gegevens op die manier veilig te gebruiken. Het tweede script verzendt gegevens naar de browser van de gebruiker, dus het moet HTML-escapefuncties gebruiken om de mogelijke manieren waarop de verwerking door de browser van die gegevens schadelijk kan zijn voor de gebruiker, te neutraliseren. HTML-ontsnapping is echter niet het enige om te overwegen; opzoeken cross-site aanvraag vervalsing.
toegevoegd de auteur Hammerite, de bron

Met betrekking tot het opschonen van datums heeft PHP een aantal ingebouwde functies die nuttig kunnen zijn. De strtotime() -functie converteert zowat elke denkbare datum/tijd-indeling naar een Unix-tijdstempel, die vervolgens kan worden doorgegeven aan de functie date() om deze naar elke gewenste opmaak om te zetten.

Bijvoorbeeld:

$ date_sql = date ("Y-m-d", strtotime ($ _POST ["date"]));

0
toegevoegd
Maar zou dit beschermen tegen injecties?
toegevoegd de auteur Matt Ridge, de bron
Dit heeft echt niets met injecties te maken omdat het op PHP-niveau gebeurt. Als u een injectie wilt voorkomen, raad ik aan voorbereide instructies te gebruiken die worden ondersteund in de php_mysqli-extensie.
toegevoegd de auteur Kris Craig, de bron
Oh en korter antwoord is: Ja, dit beschermt tegen injecties, aangezien (althans voor zover ik weet) de datum ("Y-m-d"), ongeacht de invoer, niets zal uitvoeren dat nuttig zou kunnen zijn bij een SQL-injectieaanval. =)
toegevoegd de auteur Kris Craig, de bron