[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 377
  • Last Modified:

Validating names that could contain <> symbols ie potentially malicious javascript

One of my GUIs was giving a message “A potentially dangerous Request. Form value was detected from the client”
This is because names can contain <> characters.
To stop this message one can add ValidateRequest="false” to web.config.
This leaves the application vulnerable to malicious input eg

http://www.thegeekstuff.com/2012/02/xss-attack-examples/

If the GUI converts <> to escape characters the stored procedure will need to convert them back, so I could still get malicious javascript when the browser displays the name.

The only consolation I can think of is that the name is limited to 90 characters.  How long would a string of javascript need to be to act maliciously?

This link gives some tags to look out for, but is not exhaustive.  

http://msdn.microsoft.com/en-us/library/ff649310.aspx
Any suggestions?  I'm using visual studio 2008 with asp.net 3.5 - C#
0
AlHal2
Asked:
AlHal2
  • 4
  • 3
1 Solution
 
käµfm³d 👽Commented:
If the GUI converts <> to escape characters the stored procedure will need to convert them back, so I could still get malicious javascript when the browser displays the name.
That's exactly what you should do. If you need to display these characters in an application that is something not a web browser, then yes, you will need to convert them back to regular brackets, but at that point you're not really concerned about XSS. AFAIK, all modern browsers will display HTML-encoded entities without issue, so storing them that way makes sense.
0
 
leakim971PluritechnicianCommented:
How long would a string of javascript need to be to act maliciously?

size of imagination
don't take any risk
0
 
AlHal2Author Commented:
Thanks Leakim971.

Kaufmed,

I need to display these names in a web browser.

You say "but at that point you're not really concerned about XSS"
Why not?  
If I'm really not concerned with XSS at that stage then why convert to escape characters at all?
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
käµfm³d 👽Commented:
You say "but at that point you're not really concerned about XSS"
Why not?
You're missing a bit of context:

If you need to display these characters in an application that is something not a web browser...but at that point you're not really concerned about XSS.

If I'm really not concerned with XSS at that stage then why convert to escape characters at all?
A browser will display HTML-encoded entities as the regular text equivalent. Such text won't be interpreted as, say, a <script> tag by the browser--it will be literal text. So if you HTML-encoded the brackets in your database:

&lt;script&gt;

Then you will not have a script tag once it hits the browser, you will have text that says <script>.
0
 
käµfm³d 👽Commented:
See for yourself:

Screenshot
0
 
AlHal2Author Commented:
Sorry for being slow, but are you saying we should store the names with escape characters in the database itself?   The browser will then display the names with <>?
0
 
käµfm³d 👽Commented:
Yes.
0
 
AlHal2Author Commented:
thanks.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now