Input stripping

[bindsa]

Probleem/vraag: Hoe ver moet je gaan in het strippen van input van gebruikers in web apps?
Het gaat hierbij om het controleren van bijv. namen e.d.
Huidige situatie:
Met regex patterns controleer ik of namen uitsluitend uit toegestane karakters bestaan. Zo weet ik zeker dat ik in ieder geval geen troep in mijn database(s) krijg. Meestal laat ik de volgende tekens toe: A-Z, a-z, -,

Maar deze checks kennen nadelen:
- Rare karakters zoals á worden niet getolereerd. (Terwijl bij namen deze karakters niet ondenkbaar zijn)
- Daarmee wordt de gebruiksvriendelijkheid beperkt

Dit kan je oplossen door ook de rare tekens toe te staan. Al worden dan je regex patterns complexer en langer.

Toekomstige situatie:
Binnenkort ga ik om diverse redenen binnen mijn ontwikkelomgeving over van een iso-8859-15 charset naar utf-8.
UTF-8. Één van de redenen is dat ook webapps ga ontwikkelen voor klanten die ook internationaal opereren. Andere talen dus. Met UTF-8 zouden die vreemde talen geen problemen moeten zijn. Echter, nu loop ik tegen mijn probleem van het strippen//checken van input aan, er komen namelijk nog veel meer vreemde karakters bij.

Nu zat ik te denken om te gaan switchen van alleen bepaalde karakters toestaan naar alle karakters toestaan, behalve enkele verboden karakters. Nu heb ik altijd geleerd dat dit uit beveiligingsoverwegingen niet wenselijk is.

Mijn vraag is dan ook, hoe lossen jullie dit soort dingen op? En: Als jullie sommige karakters verbieden, welke karakters zijn dat dan bij jullie?

[Y0ur1]

Waarom verbied je bepaalde karakters binnen een charset? Erg vreemd dat jij bepaalt dat letters met accenten troep zijn. Dus als ik in 't Veld heet of Andé heb ik pech? Bovendien is de term 'rare tekens' erg vreemd daar het gewoon valide letters met accenten zijn.
Doe je dit misschien om encoding issues te voorkomen? Dan is dit iig een enorme crappy 'oplossing'. Escape je de data op database niveau met bv mysql_real_escape_string?

[bindsa]

Y0ur1 schreef op zondag 13 februari 2011 @ 14:15:
Waarom verbied je bepaalde karakters binnen een charset? Erg vreemd dat jij bepaalt dat letters met accenten troep zijn. Dus als ik in 't Veld heet of Andé heb ik pech? Bovendien is de term 'rare tekens' erg vreemd daar het gewoon valide letters met accenten zijn.
Doe je dit misschien om encoding issues te voorkomen? Dan is dit iig een enorme crappy 'oplossing'. Escape je de data op database niveau met bv mysql_real_escape_string?

Ik noem die niet troep, het feit dat die verboden zijn is nu juist mijn probleem. Hoe regel jij dit soort dingen? Encoding issues heb ik helemaal geen last van. Escapen doe ik ook niet met mysql_real_escape_string, ik gebruik prepared statements.

[EdwinG]

De keuze 'alles, behalve...' is een vorm van Blacklist-validatie en inderdaad minder wenselijk dan white-list-validatie ('uitsluitend...').

Met regex patterns controleer ik of namen uitsluitend uit toegestane karakters bestaan. Zo weet ik zeker dat ik in ieder geval geen troep in mijn database(s) krijg.

Op welke manier ben je bang voor troep in je database?

• SQL-injection?
• Cross-site scripting bij het weergeven van de data?
• Niet bestaande personen in de database?

In het geval van SQL-injection is het gebruik van goede escaping of prepared statements een belangrijke (onmisbare) maatregel. (die je zo te zien al gebruikt) Er zijn genoeg situaties te bedenken waarin zelfs whitelist-validatie niet voldoende is om SQL-injection te voorkomen.

Tegen cross-site scripting, omdat de data elders weer wordt weergegeven, is uitvoer-encoding van belang. En het laatste probleem kan niet worden voorkomen door bepaalde karakters te filteren.

[Herko_ter_Horst]

De misvatting is inderdaad dat tekens die wij in Nederland niet dagelijks gebruiken "rare" tekens zijn. Internationaal gezien zijn de meeste tekens echter helemaal niet raar, maar dagelijkse kost.

Is het voor jouw applicatie belangrijk of iemand zich '$T^&O@&LA' of 'éü∫¡ºåñΩ' wil noemen in plaats van 'Jan'?

@EdwinG: op zich ben ik wel met je eens dat je beter kunt zeggen wat wel mag, om te voorkomen dat iemand iets nieuws bedenkt waardoor je blacklist niet meer werkt. In het geval van Unicode ligt al heel lang duidelijk vast wat de rol van de codepoints is. Aangezien whitelisting van alles wat wel mag in dit geval heel veel meer werk is en daardoor leidt tot situaties zoals bij de TS, wil ik toch blacklisting aanbevelen. Dit is ook geen beveilingsissue, maar een sanitycheck.

Je kunt dus beter kijken naar wat de boel echt in de soep laat lopen. Control-characters en reserved characters volgens Unicode zou je kunnen filteren. De rest gewoon toestaan en escapen waar nodig (inderdaad met prepared statements in je database, de juiste escapes in HTML en URLs).

Als je naar UTF-8 over gaat, bedenk dan wel dat je hele applicatie daar mee om moet kunnen gaat. UTF-8 characters kunnen namelijk uit meer dan 1 byte bestaan.

PS: waarom staan de meeste applicaties geen spaties toe in gebruikersnamen en wachtwoorden? Slaat echt helemaal nergens op...

[ Voor 20% gewijzigd door Herko_ter_Horst op 13-02-2011 14:47 ]

[bindsa]

Bedankt voor je reactie! Hier kan ik wel wat mee

Als je naar UTF-8 over gaat, bedenk dan wel dat je hele applicatie daar mee om moet kunnen gaat. UTF-8 characters kunnen namelijk uit meer dan 1 byte bestaan.

Ben ik me van bewust, ik ben o.a. aan het overgang op mbstring. Verder zet ik overal de encoding goed (database tabellen, database zelf, connection charset, php charset, content-encoding header, html charset, etc.)
Heb me wel redelijk ingelezen Bovendien ga ik eerst uitgebreid testen.

PS: waarom staan de meeste applicaties geen spaties toe in gebruikersnamen en wachtwoorden? Slaat echt helemaal nergens op...

Dit valt te betwisten, zo is een spatie aan het eind niet heel wenselijk (gebruiker copy-paste wachtwoord, per ongeluk spatie erbij, etc..), maarja hier bied trim() uitkomst.

[Herko_ter_Horst]

L0calh0st schreef op zondag 13 februari 2011 @ 14:47:
Bedankt voor je reactie! Hier kan ik wel wat mee


[...]


Ben ik me van bewust, ik ben o.a. aan het overgang op mbstring. Verder zet ik overal de encoding goed (database tabellen, database zelf, connection charset, php charset, content-encoding header, html charset, etc.)
Heb me wel redelijk ingelezen Bovendien ga ik eerst uitgebreid testen.

Ok, mooi

[...]

Dit valt te betwisten, zo is een spatie aan het eind niet heel wenselijk (gebruiker copy-paste wachtwoord, per ongeluk spatie erbij, etc..), maarja hier bied trim() uitkomst.

Aan het begin en het eind zijn grensgevallen. Maar daar kun je de gebruiker ook voor waarschuwen (nadat het geprobeerd hebt). Maar verder... Mijn "nick" is Herko_ter_Horst, puur en alleen omdat ik op veel plekken geen spaties mag/mocht gebruiken. Waarom mag ik niet gewoon mijn naam gebruiken?

[RobIII]

L0calh0st schreef op zondag 13 februari 2011 @ 14:47:
Dit valt te betwisten, zo is een spatie aan het eind niet heel wenselijk (gebruiker copy-paste wachtwoord, per ongeluk spatie erbij, etc..), maarja hier bied trim() uitkomst.

Blijf van wachtwoorden af! Niet strippen, niet lower/uppercasen om ze case-insensitive te maken of andere stringbewerkingen erop los laten. Als ik een spatie in mijn wachtwoord heb (en wil) moet dat kunnen. Basta.

Dat je een naam trimmed; prima. Spaties komen nou eenmaal niet voor in namen (althans, niet ervoor en/of erna). Maar ook hier: blijf van casing e.d. (of 'stringnormalisaties' als é->e) af.

[ Voor 16% gewijzigd door RobIII op 13-02-2011 14:56 ]

[bindsa]

RobIII schreef op zondag 13 februari 2011 @ 14:54:
[...]

Blijf van wachtwoorden af! Niet strippen, niet lower/uppercasen om ze case-insensitive te maken of andere stringbewerkingen erop los laten. Als ik een spatie in mijn wachtwoord heb (en wil) moet dat kunnen. Basta.

Wat is er mis met zoiets dan:

PHP:

<?php
if($password != trim($password)) {
   $message = "Bent u zich ervan bewust dat uw wachtwoord een spatie aan het begin/einde heeft?";
}
?>

Op zoiets doelde ik namelijk...

[RobIII]

L0calh0st schreef op zondag 13 februari 2011 @ 14:57:
[...]


Wat is er mis met zoiets dan:

PHP:

<?php
if($password != trim($password)) {
   $message = "Bent u zich ervan bewust dat uw wachtwoord een spatie aan het begin/einde heeft?";
}
?>

Op zoiets doelde ik namelijk...

Bouw dan ook meteen even:

code:

"Bent u zich ervan bewust dat uw wachtwoord een $ bevat? Bedoelde u 4?"
"Bent u zich ervan bewust dat uw wachtwoord een 4 bevat? Bedoelde u $?"
"Bent u zich ervan bewust dat uw wachtwoord een é bevat? Bedoelde u 'e en staat uw toetsenbord verkeerd ingesteld?"
"Bent u zich ervan bewust dat uw wachtwoord een é bevat? Bedoelde u 0233 maar hield u perongeluk de ALT toets ingedrukt of er ligt een boek op?"
"Bent u zich ervan bewust dat uw wachtwoord een A bevat? Bedoelde u a?"

Wat roest 't als er een spatie in een wachtwoord zit? Daarbij: als je enkel een hash over de lijn stuurt (zoals T.net dat bijv. doet mits JS aanstaat) is het een beetje lastig bepalen of er een spatie in zit he?

[ Voor 24% gewijzigd door RobIII op 13-02-2011 15:03 ]

[bindsa]

Wat roest 't als er een spatie in een wachtwoord zit? Daarbij: als je enkel een hash over de lijn stuurt (zoals T.net dat bijv. doet mits JS aanstaat) is het een beetje lastig bepalen of er een spatie in zit he?

No offense, maar mij gaat het niet om het karakter op zich, maar het feit dat users wachtwoorden vaak copy-pasten en daarbij per-ongeluk een spatie meepakken en dus later een verkeerd wachtwoord proberen in te voeren. Als je een hash over de lijn stuurt doe je die check toch gewoon met JavaScript? Ik heb hier puur het gebruiksgemak van de user voor de ogen, mij of mijn database kan het niet schelen als er een spatie in zit...

[Herko_ter_Horst]

Het lijkt me niet verstandig users te gaan stimuleren in het copy/pasten van wachtwoorden...

[CodeCaster]

L0calh0st schreef op zondag 13 februari 2011 @ 15:04:
[...]

No offense, maar mij gaat het niet om het karakter op zich, maar het feit dat users wachtwoorden vaak copy-pasten en daarbij per-ongeluk een spatie meepakken en dus later een verkeerd wachtwoord proberen in te voeren. Als je een hash over de lijn stuurt doe je die check toch gewoon met JavaScript? Ik heb hier puur het gebruiksgemak van de user voor de ogen, mij of mijn database kan het niet schelen als er een spatie in zit...

Ben je niet een niet-bestaand probleem aan het oplossen? Hoeveel gebruikers ken jij die per ongeluk een spatie achter hun wachtwoord plakken? Stuur je een e-mail met daarin het wachtwoord dan heb je daar je probleem: gebruik een activatielinkje waarna gebruikers zelf hun nieuwe wachtwoord kunnen intikken.

[Remus]

Herko_ter_Horst schreef op zondag 13 februari 2011 @ 15:25:
Het lijkt me niet verstandig users te gaan stimuleren in het copy/pasten van wachtwoorden...

Ik doe het anders regelmatig doordat ik inmiddels een groot deel van mijn wachtwoorden echt niet meer kan onthouden (lang leve KeePass)

[RobIII]

KeePass neemt geen spaties mee als er geen spaties in zitten. Dit "probleem" heb je alleen als je copy/paste uit een email, Word document, webpagina ofzo.

[Soultaker]

Ik vind het als gebruiker enorm irritant als sites mijn unieke, sterke wachtwoorden niet accepteren door idiote en volstrekt willekeurige eisen te stellen aan welke karakters er niet in mogen of juist wel in moeten voorkomen. Ik kan me voorstellen dat het ook frustrerend is als je je naam of adres niet kunt invullen omdat de site overdreven restrictief is.

Het lijkt me dus beter om er van uit te gaan dat degene die het formulier invult weet waar 'ie mee bezig is, en achteraf desnoods fouten aan te passen, dan om potentieel geldige invoer te weigeren tot frustratie van de gebruiker.

RobIII schreef op zondag 13 februari 2011 @ 15:00:
Daarbij: als je enkel een hash over de lijn stuurt (zoals T.net dat bijv. doet mits JS aanstaat) is het een beetje lastig bepalen of er een spatie in zit he?

In dat geval kun je die correctie ook client-side uitvoeren natuurlijk.

[creator1988]

Eyeopener: http://www.kalzumeus.com/...mers-believe-about-names/

[ Voor 6% gewijzigd door creator1988 op 14-02-2011 18:21 ]

[bindsa]

creator1988 schreef op maandag 14 februari 2011 @ 18:21:
Eyeopener: http://www.kalzumeus.com/...mers-believe-about-names/

Thanks! Daar kan ik wel wat mee

[MSalters]

Strings MOET je normaliseren. Unicode staat toe om karakters zoals é te coderen als e' dus met een los accent (diacritical). Dat geeft andere resultaten met password hashes.

[bindsa]

MSalters schreef op dinsdag 15 februari 2011 @ 18:49:
Strings MOET je normaliseren. Unicode staat toe om karakters zoals é te coderen als e' dus met een los accent (diacritical). Dat geeft andere resultaten met password hashes.

Huh? Dat snap ik even niet. Als een client een é typt door e' dan krijg ik toch bij de server nog steeds de é binnen? Dan zou je zeggen dat het niet uit maakt. En als wat ik zeg niet klopt, hoe normaliseer je strings dan?

[RobIII]

edit:
nvm

Hier staat 't beter uitgelegd.

[ Voor 96% gewijzigd door RobIII op 15-02-2011 20:57 ]

[bindsa]

RobIII schreef op dinsdag 15 februari 2011 @ 20:46:

edit:
nvm

Hier staat 't beter uitgelegd.

Hier kan ik wel wat mee Bedankt!