Re^2: Any security holes?

(Just for the records, I know you know this already! =)

> to help mitigate this is to escape any strings ... HTML::Entities.

Yes escaping mitigates injections, and is a good first workaround.

But I always prefer to strictly reject any unexpected character.

For instance, why should an input "age" include anything else than digits, why "name" more than word characters plus maybe . - and ' ?

Additionally: In my applications I apply the exact same regex filter rules via JS input validators on the client side too.²

Like this I can not only reject broken input on the server side, but also raise an alarm about an intentional manipulation. °

All this of course plus escaping or use of placeholders on all interpreted levels (HTML,JS,Perl,SQL,...).

Security is best provided by multiple lines of defense.

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery}

°) thats part of OWASP too.

²) thankfully, JS copied Perl4 Regex rules almost completely

Comment on Re^2: Any security holes?

Replies are listed 'Best First'.
Re^3: Any security holes? by hippo (Archbishop) on Jun 26, 2022 at 19:41 UTC
why "name" more than word characters plus maybe . - and ' ? See the excellent Falsehoods Programmers Believe About Names. I recognise and applaud your general sentiment but you need to be very careful about rejecting potentially valid data too. If in doubt, refer to the spec. If there is no spec, insist on one. 🦛	[reply]
Re^4: Any security holes? by Your Mother (Archbishop) on Jun 26, 2022 at 19:47 UTC
Ha! I only look like a biter. I didn’t see your reply, reading down in order, until I had posted mine.	[reply]
Re^4: Any security holes? by LanX (Saint) on Jun 26, 2022 at 20:21 UTC
I was too lazy to come up with another field like maybe "ZIP-code" ... mea culpa. The intranet app I wrote back then was one for password resetting for the 10k+ users of our services inside our company. The "name" I'm referring to, was actually our normalized, standardized and unique employee-id inside our company. It actually only allowed `/[a-z]/i` (IIRC) and no space and is modelled roughly after `"given-name"."family-name"` But some of my colleagues allowed users to choose other usernames in our applications, but that's another story. I never wrote an app requesting users to register with their "real name". Anyway you two are right and I was wrong. > If in doubt, refer to the spec. I did. :) FWIW: I recently managed to skip a letter in my own family name on a flight ticket I booked online and panicked. Was no problem at all, turned out that airlines are allowed to accept up to 3 deviations. I think this is related to the article you and your mother° cited. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery} °) ;-P edit PS: Names_of_Sun_Yat-sen	[reply] [d/l] [select]
Re^4: Any security holes? by Jenda (Abbot) on Jun 27, 2022 at 19:55 UTC
That article somehow reminded me of this video: https://www.youtube.com/watch?v=1LopIroSjsU And while I agree there is no need to be overly restrictive when it comes to names, some people deserve a good kick in the butt and a little ridicule ... and being forced to come up with a sane version of their name. Jenda 1984 was supposed to be a warning, not a manual!	[reply]
Re^3: Any security holes? by hv (Prior) on Jun 26, 2022 at 17:54 UTC
why "name" more than word characters plus maybe . - and ' ? I hope the space between '.' and '-' is significant: it is thankfully rarer these days, but I've lost count of the number of times I was rejected by a web form because "van der Sanden" did not match their concept of a valid surname. In the majority of cases, those websites lost the chance at my custom. Finding the right balance between strict and permissive can be hard. My preference is to look for unmistakable signals of intentional manipulation - and then ideally blackhole the IP address without further ado - but to accept anything below that high threshold, and concentrate on doing the right thing with it thereafter.	[reply]
Re^4: Any security holes? by LanX (Saint) on Jun 26, 2022 at 18:10 UTC
Granted, I knew "name" was a bad example. Space goes without saying, and I might be ignoring more legal letters. A good mechanism should always include a backfeed channel for critic and adjustment. Though I remember having a fight with one of my colleagues who insisted that one of his clients can continue to use emojis in his user name and me having to hardcode an exception into the app ... I never "adjusted" this. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery}	[reply]
Re^5: Any security holes? by Your Mother (Archbishop) on Jun 26, 2022 at 19:46 UTC
I know you know and I always sort of knew too but it wasn’t until I saw this that I really knew. :P Falsehoods Programmers Believe About Names. I agree, of course, that whitelisting is drastically better security than blacklisting in the general case. Update: hippo beat me to it.	[reply]

edit