this post was submitted on 24 Feb 2024
18 points (90.9% liked)
Cybersecurity
5456 readers
173 users here now
c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.
THE RULES
Instance Rules
- Be respectful. Everyone should feel welcome here.
- No bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia.
- No Ads / Spamming.
- No pornography.
Community Rules
- Idk, keep it semi-professional?
- Nothing illegal. We're all ethical here.
- Rules will be added/redefined as necessary.
If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.
Learn about hacking
Other security-related communities !databreaches@lemmy.zip !netsec@lemmy.world !cybersecurity@lemmy.capebreton.social !securitynews@infosec.pub !netsec@links.hackliberty.org !cybersecurity@infosec.pub !pulse_of_truth@infosec.pub
Notable mention to !cybersecuritymemes@lemmy.world
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
That's great if every external library and application also expects usernames that can contain every character, but mostly they won't. If you're very good about testing, you might catch every instance where they don't, but that doesn't mean you can necessarily fix them / get them fixed.
Plus, there's just displaying them. If you have sane limits on usernames, you can have sane user management tools that do things that list users vs. storage used, or whatever. If a username might contain backspace characters or who knows what else, all those tools have to be made more complicated too.
In addition, there's user support. If you allow usernames to contain zalgo text, you're going to have far more users needing support because they're having trouble entering their username. You're also going to give your support people nightmares trying to help those users out.
"Ok, I see you entered your username as "s̶u̵g̶a̴r̴_̵i̷n̴_̵y̶o̸u̷r̸-̴t̴e̷a̴" not "s̶u̵g̵a̶r̷_̶i̴n̸_̸y̵o̴u̵r̷_̸t̵e̵a̷", could you try re-entering that username and see if that fixes the problem?"
If your libraries aren't using proper SQL practices (or any other DB), you should get better libraries. Something like a username should be treated as just bytes by your backend services, so there should never be an issue.
If your frontend wants to limit usernames, that's fine. But that's not a security issue, but a display issue.
Why are you imagining this just has to do with SQL? You have a very narrow view of the problem and as a result you're going to cause yourself massive headaches.
For a username, your backend should only do simple CRUD:
Other than that, you should be using a backend-generated ID, like a UUID or a login token, elsewhere in your application. So for the backend, your only concern related to secure handling of a username is the proper handling of SQL queries for those operations and encoding over the wire. Wire encoding is well defined (URL-encoding or base64), and SQL injection isn't a thing if you use a decent library correctly. Don't try to interpret it anywhere, just pass it along as a bunch of bytes, just like a password.
So the only thing left is the frontend, where you should be sanitizing all user input anyway. If the frontend wants to sanitize input in some way, ensure the backend has the same check on creates and updates. But that has nothing to do with backend security, it's merely a convenience to prevent bugs on the frontend.
Ok, but that wasn't the question. The question was "Should you allow username to use Apostrophe (aka quotes )".
There's no mention of what the role of the backend is, just the question of what that policy choice should be. By looking at it only through the lens of the backend, you're going to cause headaches.
We're in a community focused on cyber security, and the question linked this stack exchange thread, which is explicitly about SQL injection. From that article:
The context is SQL injection, which typically is a backend thing. That's why I talked about BE vs FE. You could instead say "DB layer" vs "presentation layer" if you prefer.
But my point is that removing single quotes in the context of cyber security completely misses the point. Only remove single quotes (or any other character) if it makes sense for your application use case, not for some vague sense of "security." If allowing single quotes causes a security vulnerability, your code is wrong even if you disallow single quotes.