my client is saying that she couldn't register on our website and getting error
When she was registering, she would enter all the information, and when she would click through, an error message would tell her that the name field only allowed letters and not numbers. She wasn't entering any numbers.
Could this be a problem with her browser? (She is using Internet Explorer.) Her computer? What else could it be?
I tried it, and it worked for me.
i am using regular expression
ValidationExpression="^[A-Za-z]+$".
She might not be entering numbers, but is that all your error message states?
She might be entering punctuation, symbols, or spaces.
Copying and pasting something in could also leave a trailing space which would fail your validation.
Perhaps her name has a hyphen, apostrophe or accented character in it. If it is a full name, then it is probably erroring on the space between the forename and surname!
Avoid restricting what users are allowed to input as you'll usually end up stopping people from entering things that should be perfectly acceptable, just use suitable escape sequences (e.g. with paramertised queries for databases or converting <, >, &, " and ' to their respective entities for HTML) before putting the data anywhere.
I'm assuming you're not a technical person. The chances are that the name entered has and apostrophe, space, or anything that isn't between a-z.
The reason you are getting this message is because whoever created the system has told is to say that when the name doesn't match the regular expression, even though it probably has nothing to do with entering a number.
Ok, I'll say it a thousand times. Never assume what the end user is saying is true or what they claim to be doing is what they actually are doing. Not that they are deceitful, just they often don't know.
I recommend using a remote desktop software such as Co-Pilot (no, I don't work for fogcreek) and connecting to any user that can replicate this issue and view it happening for yourself.
Once you can verify it is indeed happening, you should be able to replicate it from your end and then submit it to the developers (or yourself) to be fixed
I'ts not a browser-related problem. ASP.NET form validation is server-side.
Related
We have a fairly complicated ASP.NET MVC project with cross domain login widgets and a lot of semi-legacy code.
There is a system where we login people through an iframe. The url for the iframe we send through a string attached to the MVC Model.
Problem is; on really rare occassions we see malformed query string parameters coming through. It's always the same malformation though. I want to fix the issue, but I can't figure out why this happens.
I'm expecting some Adblocker-type or privacy settings, or maybe some Regional settings, but I have no clue where to start.
I am hoping someone will recognize the pattern and say; that's a localization pattern when your Windows is set on Turkey or whatever, you should check your encoding etc etc.
Anyway here's the example:
Expected:
auth-dialog-window?openerOrigin=https%3a%2f%2f.poules.com&color=C3042E&openerType=iframe
Coming through:
auth-dialog-window?color=P304212R&openerType=vsenzr&openerOrigin=uggcf%3N%2S%2Scbhyrf.pbz
Apparently the order of the query string also changes. Here more closely per parameter:
iframe
vsenzr
https:// poules.com (spaces are for aligning)
uggcf%3N%2S%2Scbhyrf.pbz
C3042E
P304212R
Does anyone recognize the pattern and can give me a hint where I should be looking?
I know for sure the last time it happened with IE 9.0, but can't reproduce it.
ROT-13.
A system somewhere is "trying to crypt" in a very simple way...
Check "pairs" of letters in both values:
abcdefghijklmnopqrstuvwxyzabcdefghijklm
nopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
I've encountered a Oracle Form which has a strange behavior. It seems that it looses the spanish character "ñ" when converting it from Oracle 10gR2 to Oracle 11gR1. This only seems to happen in Text Field Prompts. The rest of the elements in the form seem to display the characters properly. Any suggestions as to what might cause this or what to check to fix it? I've already have checked that the fonts installed support this character and that the NLS related settings look ok.
Well, after a whole day trying to determine what the problem was, it seems that the simplest answer was the right one: The original developer for this form seemed to want to assure that the character was displayed properly and he had a bad setup, so he was setting the text using the SET_ITEM_PROPERTY function, and using the CHR function to escape the character. Something like the following:
SET_ITEM_PROPERTY('BLOCK.PASS_FIELD', PROMPT_TEXT, 'Contrase'||CHR(241)||'a: ');
That for the prompts for the fields which were titled "Contraseña: " in their properties.
In the current set up, it works, but on this new environmet, we are using an UTF8 encoding and the code for the letter "ñ" changes completely. Just for the sake of completeness the code in utf8 would be CHR(50097). But I suggest it would be better just to ask your DBA or SYSADMIN to fix the NLS settings so you can just use the prompt or field properties and don't have to get this "creative" and make other dev waste too much time.
It never ocurred to me to check for this, because the properties seemed to be set up correctly, but a simple test of creating a new field with the same properties finally showed me that the problem was specific to the 4 fields which were already created and searching for code-based attribute changes led me to find this was the issue. So I leave this answer here in the hope that someone else saves a few hours of his time and checks for the simple answer first.
I am testing out security and reliability issues on my site. I have made \n and \r illegal. I created a user with null in the name which caused my PM system to not message the user. However \b worked and \t didnt allow copy/paste to work correctly. The browser (firefox which i am testing with) copied the tab as a single space causing the name not to be the same thus not recognizing the username. Since i cant copy paste easily i'll probably disallow it. \f works as well although i do see a symbol in the title but nowhere else because of the \f.
What else should i try? It appears 0-31 127-159 (i dont understand this range) are illegal. What characters in legal range might i want to disallow? I heard there was a 0 width character space. That may be something i want to disallow? What else is there?
-edit- It appears those ranges are allowed if i escape them using &#DECIMAL_VALUE;. So i can allow \b and etc. What do you guys think about this? Its kind of fun seeing the results and if something works + effects VS breaks
It may well be easier to have a whitelist of characters that the user can use for a username and just remove anything not in that list...
We have a very strange problem in out application, all of a sudden we started noticing
upside down question marks being saved along with other text typed in to the fields on the screen. These upside down question marks were not originally entered by the users and it is unclear where they come from. We are using Oracle 10g with Asp.Net.
Here is an example of the issue: "140, 141) ¿ 16-Oct-07". If any one have seen this before and found a way to fix this please let me know how.
This sounds like a character encoding issue. Please check what encoding your database (tables) are set to, and what encoding the objects or strings which are passing data in the database are of. If there is a mis-match (DB in ANSI, App in UTF-8), these sorts of issues can appear.
Greg, you should check NLS_CHARACTERSET not NLS_NCHAR_CHARACTERSET settings. And I bet you it's WE8ISO8859P1 or something similar and not unicode. The problem occurs when the submitted data in unicode, which is probably UTF8, and Oracle tries to map the characters to WE8ISO8859P1 character set. It does fine for most of them but fails for high ASCII number characters, like 140.
So yes, I have seen the same issue in our application and in our case it was caused by special quote marks (“example”, ‘example’) that were copied from MS Word. Word automatically converts double quotes to some other quotes. The solution was to convert the database to UTF-8.
IF your users are copying from MS Word you can turn the feature off . Its part of the autocorrect/autoformat functionality. If you uncheck the replace options for quotes and apostrophes you should be ok. Be sure turn off the replacements in both the AutoFormat and AutoFormat as you type.
I'm creating an Asp.Net program UI where users can browse and change information in a database. For this reason, they need to be able to use all forms of chars, but I still need to keep the program HTML and SQL itself secure. For that reason, I'm using a self-built method that replaces dangerous chars such as '<' etc with their html-codes while they're being handled outside of a textbox (issued on page-load so they have no functionality in there).
Now my dilemma: To be able to do this, I have to disable the Validaterequest parameter as per the topic, the program will issue a complaint. What are the possible consequences of setting it to False?
The SQL query is parametirized already, and I filter out the following marks only:
& # < > " ’ % # =
Question: am I leaving the program open for threats even if I handle the chars above? Basically this is an intranet application where only a few people will be able to access the program. Nevertheless, the information it accesses is fairly important so even unintentional mishaps should be prevented. I literally have no idea what the Validaterequest thing even does.
Edit: Alright, thx for the answers. I'll just go with this then as initially planned.
The main things Validate Request is looking for are < and > characters, to stop you opening your site up to malicious users posting script and or HTML to your site.
If you're happy with the code you've got stripping out HTML mark-up, or you are not displaying the saved data back to the website without processing, then you should be ok.
Basically validating user input by replacing special characters usually cause more trouble and doesn't really solve the problem. It all depends what the user will input, sometimes they need the special characters like
& # < > " ’ % # =
think about savvy users could still use xp_ command or even use CONVERT() function to do a ASCII/binary automated attack. As long as you parametrized all input, it should be ok.
i think that the problem is not only about SQL injection attacks, but about Cross Site Scripting and JS execution attacks.
To prevent this you cannot rely on parametrized queries alone, you should do a "sanitization" of the html the user sends! maybe a tool like html tidy could help.