I have a doubt about validating user LogIn.why User name can not be start with special character is there any technical reason or its just due to naming convention only.Can any one clarify this.
It is your system. If you want to allow special characters in user names, then do it.
Related
I have searched for an answer to this, but unfortunately I have had little luck in finding any information on it!
In essence: What is the set of valid names for a memory mapped file in windows?
How long can they be?
What are legal characters, e.g. are forward slashes, hyphens, punctuation, etc. legal?
Are there limitations on character ordering, e.g. an mmf name cannot start with an underscore?
EDIT: I realize that the answer to this question might be "They are exactly the same as normal file naming conventions in Windows." However it is important that this be clarified.
MemoryMappedFile.CreateNew corresponds to CreateFileMapping. The documentation for CreateFileMapping says
The name can have a "Global\" or "Local\" prefix to explicitly create
the object in the global or session namespace. The remainder of the
name can contain any character except the backslash character (\).
Creating a file mapping object in the global namespace from a session
other than session zero requires the SeCreateGlobalPrivilege
privilege. For more information, see Kernel Object Namespaces.
In other words, you can use any string you like as long as it doesn't contain a backslash.
I do not want to be too strict as there may be thousands of possible characters in a possible first name
Normal english alphabets, accented letters, non english letters, numbers(??), common punctuation synbols
e.g.
D'souza
D'Anza
M.D. Shah (dots and space)
Al-Rashid
Jatin "Tom" Shah
However, I do not want to except HTML tags, semicolons etc
Is there a list of such characters which is absolutely bad from a web application perspective
I can then use RegEx to blacklist these characters
Background on my application
It is a Java Servlet-JSP based web app.
Tomcat on Linux with MySQL (and sometimes MongoDB) as a backend
What I have tried so far
String regex = "[^<>~##$%;]*";
if(!fname.matches(regex))
throw new InputValidationException("Invalid FirstName")
My question is more on the design than coding ... I am looking for a exhaustive (well to a good degree of exhaustiveness) list of characters that I should blacklist
A better approach is to accept anything anyone wants to enter and then escape any problematic characters in the context where they might cause a problem.
For instance, there's no reason to prohibit people from using <i> in their names (although it might be highly unlikely that it's a legit name), and it only poses a potential problem (XSS) when you are generating HTML for your users. Similarly, disallowing quotes, semi-colons, etc. only make sense in other scenarios (SQL queries, etc.). If the rules are different in different places and you want to sanitize input, then you need all the rules in the same place (what about whitespace? Are you gong to create filenames including the user's first name? If so, maybe you'll have to add that to the blacklist).
Assume that you are going to get it wrong in at least one case: maybe there is something you haven't considered for your first implementation, so you go back and add the new item(s) to your blacklist. You still have users who have already registered with tainted data. So, you can either run through your entire database sanitizing the data (which could take a very very long time), or you can just do what you really have to do anyway: sanitize data as it is being presented for the current medium. That way, you only have to manage the sanitization at the relevant points (no need to protect HTML output from SQL injection attacks) and it will work for all your data, not just data you collect after you implement your blacklist.
Your opinions please.
In our system the decision was made that all fields (except notes) will be forced into uppercase. I don't like it, but the system's intended users aren't very computer literate, so for line-of-business use I suppose it is acceptable.
When it comes to email addresses however, would you also force them into uppercase, against the lowercase convention?
The part before # "Local Part" is "locally interpreted" (see RFC 2822 ยง3.4.1).
This could include being case-sensitive. Whether any email processing agents support case sensitivity is another question.
Email addresses are case-insensitive, so it doesn't matter. Upper case would be fine.
We have a form that has fields for first and last name. I was asked to allow underscores. I don't know of any sql injection that uses underscores, but I also don't know of anyone with an underscore in their name. Is there a good reason to allow or not allow underscores in names?
EDIT: I'm using parameters and server side validation. This is for client side validation via the jQuery validation plugin.
EDIT 2: I didn't mean for this to become a discussion on whether or not I should do any validation...I just wanted to know know if there was any compelling reason to accept underscores, like I should accept Irish people or hyphens. Based on that, I'm accepting Oren's answer.
You should be as liberal as possible in what you allow as a name. There is no good reason to disallow an underscore, so why do it? There are many horror stories of people who try to utilize software that disallows their actual name. Have a look at Falsehoods Programmers Believe About Names for assumptions you should not make.
DO NOT PREVENT SQL INJECTION USING WHITELISTS!
Have you come across an O'Neill yet?
Instead, use parameters.
I will admit, though, that whitelists will work better than blacklists
Re: EDIT:
You should not do such validation at all.
If your server-side code can handle it, there's nothing wrong with the name --'!#--_.
If your server-side code cannot handle it, it should.
You're doing your validation wrong. When preventing sql injection, just use placeholders or your database library's escape function to escape the data. What characters you use in the name doesn't matter then.
You'll need to allow apostrophes and hyphens (O'Reilly, Double-Barrel). Never heard of an underscore in a name though.
Ideally, you should be able to allow any characters and not have a problem with SQL injection because you are using parameterized queries etc.
Do you disallow '? How do you think Mr O'Reilly likes that?
If you prevent underscores with the assumption that we are not aware of names with underscores, would you do the same for the other dozens (hundreds) of other "special characters"?
Unless there is some reason to block underscores, I would leave it up to the user to be able to enter their name as they want.
I've got a (proprietary) output from a software that I need to parse. Sadly, there are unescaped user names and I'm scratching my hairs trying to know if I can, or not, describe the files I need to parse using a BNF (or EBNF or ABNF).
The problem, oversimplified (it's really just an example), may look like this:
(data) ::= <username>
<username> ::= (other type of data)
And in some case, instead of appearing at the left or at the right, the username can also appear in the middle of a line.
The problem is that the username is unescaped and there are not enough restrictions on user names (they're printable ASCII, max 20 chars and they can't contain line break). So "=" would be a perfectly valid username, for example. And so would "= 1 = john = 2" (because user, at sign-on, where allowed to choose any user name they wanted and these appear unescaped in the output I've got).
I'm asking because my parser chocked on some very creative usernames (once again, not in my control, they're "weird" and I need to deal with it) and I cannot find an easy way to deal with this. Also note that I do not know in advance the user names (for example I don't have access to a database that would contain all the user names that the users created).
So are unrestricted and unescaped user names incompatibles with BNF?
P.S: be cool with me if I made mistakes, it's my first post on stackoverflow :)
BNF doesn't "care" for user names per-se. It works on the token level. If you define a username token, you can build describe a grammar using BNF based on it.
Your problem should be solved on the lexer level. The lexer should be smart enough to recognize user names, even when they're not escaped, and pass username tokens to the parser.
In theory you could describe all kinds of user names with a grammar, but this heavily depends on the other things in your language. Is = a valid token on its own right? How can you tell a username having = in it apart if it is? I think you'll have to describe the rest of the rules and valid tokens in your language to get a fuller answer here.
It might be possible to work by recognising things that are not usernames and then declaring everything else a username, even if this means parsing from right to left instead of left to right or doing something equally eccentric.
It may be worth looking to see if your input is actually ambiguous: can you find two different situations that lead to identical output being generated? If so, you need to go back and get requirements for which of them to favour, or what sort of error to produce, or whatever. If not, the reason why not might help you work out what your parser or lexer or whatever needs to do.