Zijn deze twee functies overkill voor ontsmetting?

Eerlijk gezegd denk ik dat de auteur van deze functie geen idee heeft wat XSS- en SQL-injecties zijn of wat de gebruikte functie precies doet.

Om maar twee eigenaardigheden te noemen:

Gebruik stripslashes na mysql_real_escape_string verwijdert de schuine strepen die zijn toegevoegd door mysql_real_escape_string .
htmlentities vervangt de chatacters < en > die worden gebruikt in strip_tags om tags te identificeren.

Verder:Over het algemeen zijn functies die beschermen tegen XSS niet geschikt om te beschermen tegen SQL-injecties en vice versa. Omdat elke taal en context zijn eigen speciale karakters heeft waar voor gezorgd moet worden.

Mijn advies is om te leren waarom en hoe code-injectie mogelijk is en hoe u zich hiertegen kunt beschermen. Leer de talen waarmee u werkt, vooral de speciale tekens en hoe u hieraan kunt ontsnappen.

Bewerken Hier is een (waarschijnlijk raar) voorbeeld:Stel u voor dat u uw gebruikers een waarde laat invoeren die moet worden gebruikt als een padsegment in een URI die u in een JavaScript-code gebruikt in een onclick Attribuutwaarde. Dus de taalcontext ziet er als volgt uit:

HTML-kenmerkwaarde
- JavaScript-tekenreeks
  - URI-padsegment

En om het nog leuker te maken:je slaat deze invoerwaarde op in een database.

Om deze invoerwaarde correct in uw database op te slaan, hoeft u alleen maar een juiste codering te gebruiken voor de context waarin u die waarde in uw databasetaal gaat invoegen (d.w.z. SQL); de rest doet er (nog) niet toe. Aangezien u het in een SQL-tekenreeksdeclaratie wilt invoegen, zijn de contextuele speciale tekens de tekens waarmee u die context kunt wijzigen. Wat tekenreeksdeclaraties betreft, zijn dit (vooral) de " , ' , en \ tekens die moeten worden ontsnapt. Maar zoals eerder vermeld, doen voorbereide verklaringen alles wat voor u werkt, dus gebruik ze.

Nu u de waarde in uw database hebt, willen we deze correct uitvoeren. Hier gaan we van de binnenste naar de buitenste context en passen we de juiste codering toe in elke context:

Voor het URI-padsegment context we moeten (tenminste) ontsnappen aan al die tekens waarmee we die context kunnen veranderen; in dit geval / (laat het huidige padsegment achter), ? , en # (beide verlaten de URI-padcontext). We kunnen rawurlencode gebruiken hiervoor.
Voor de JavaScript-tekenreeks context waar we voor moeten zorgen " , ' , en \ . We kunnen json_encode gebruiken hiervoor (indien beschikbaar).
Voor de HTML-kenmerkwaarde we moeten zorgen voor & , " , ' , en < . We kunnen htmlspecialchars gebruiken hiervoor.

Nu alles bij elkaar:

'… onclick="'.htmlspecialchars('window.open("https://example.com/'.json_encode(rawurlencode($row['user-input'])).'")').'" …'

Als nu $row['user-input'] is "bar/baz" de uitvoer is:

… onclick="window.open(&quot;https://example.com/&quot;%22bar%2Fbaz%22&quot;&quot;)" …

Maar het gebruik van al deze functies in deze contexten is geen overkill. Want hoewel de contexten vergelijkbare speciale tekens kunnen hebben, hebben ze verschillende escape-reeksen. URI heeft de zogenaamde procentcodering, JavaScript heeft escape-reeksen zoals \" en HTML heeft tekenreferenties zoals " . En als je niet slechts één van deze functies gebruikt, kan de context worden verbroken.