Solved

XSS and SQL Injection attacks

Posted on 2010-09-07
10
648 Views
Last Modified: 2012-05-10
Hi!

I'm developing a website ASP.net with SQL Server.

When I have to check the user's input?

Only in query forms?
Both in query and registration (insert) forms?

It's a good approach add a validator against XSS in every single textbox that receives user's input?
What about validators to check against SQL Injection? May I (or should I) use them? Or just let the native protection of DataSet to this work?

Thanks in advance!
0
Comment
Question by:calypsoworld
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
  • 2
  • +1
10 Comments
 
LVL 2

Accepted Solution

by:
bureshd earned 286 total points
ID: 33620689
Use stored procedures on the SQL side and you shouldn't have to worry about injection. Too much restriction is always better than not enough. I'm a big fan of regular expressions for validation and javascript for limiting input fields. If you don't think a user will need a certain character, don't allow it. That's about as basic as it gets.
0
 
LVL 23

Assisted Solution

by:Jens Fiederer
Jens Fiederer earned 143 total points
ID: 33620745
Whether you use stored procedures or select/update statements, the key to avoiding SQL injection is to NOT use user input to format your statement (using a stored procedure as bureshd suggested makes that trivial, but sometimes the database is "owned" by a group that restricts your ability to create your own stored procedures).

Thus
     "UPDATE myTable SET FOO = " + userinput.Text
is an invitation to injection attacks, but

statement.text = "UPDATE myTable SET FOO = %1"

with the corresponding parameter set to the value of userinput.Text is injection-proof.
0
 
LVL 2

Assisted Solution

by:bureshd
bureshd earned 286 total points
ID: 33620782
jensfiederer is correct on the use if you don't have the ability to protect yourself from that on the database side via stored procedures. Either use parameters in your code or in your procedures, both accomplish the same thing.
0
The Eight Noble Truths of Backup and Recovery

How can IT departments tackle the challenges of a Big Data world? This white paper provides a roadmap to success and helps companies ensure that all their data is safe and secure, no matter if it resides on-premise with physical or virtual machines or in the cloud.

 

Author Comment

by:calypsoworld
ID: 33620908
Ok, thank you for replies!

What about XSS (Cross Site Scripting).
May I (or should I) have a validator in every textbox with a regular expression

(&#|[^<>#&])*

to avoid < > $ #

?

XSS is about embbeded HTML or script , right? It makes sense to check the "user registration from" against XSS? I mean, the data will be stored on db and will not be necessarily shown on page.

Thank you!
0
 
LVL 2

Assisted Solution

by:bureshd
bureshd earned 286 total points
ID: 33621196
I would have a validator to not allow those characters to be submitted. I would also validate them on the code behind to make sure those characters never got by prior to inserting into a DB. Again, stored procedures or parameterized strings will allow users to enter that info and not have a negative effect. I'm more the type to not allow the characters, rather than allow them and protect yourself from them.
0
 

Author Comment

by:calypsoworld
ID: 33621452
Ok.

So, parameterized strings allows a text that contains a XSS attack string because it does not affect the DB. The problem is if the string will be shown on a page. Right?

XSS attack and SQL injection are two very distinct vulnerabilities, right?

Thank you!
0
 
LVL 23

Assisted Solution

by:Jens Fiederer
Jens Fiederer earned 143 total points
ID: 33621501
Right and right, although there are similarities; one is exposing the database and the other the user's browser to randomly, especially maliciously, entered text.  

If you can restrict the input to a "safe" character set as bureshd suggests, that stops BOTH forms of attack.
0
 
LVL 2

Assisted Solution

by:bureshd
bureshd earned 286 total points
ID: 33621514
Correct, from a DB standpoint, XSS is a moot point. IT just stores the information as text and will produces this text when commanded to. If you are then going to be using that stored information, you will need to make sure it isn't an XSS attack. Once it has been shown on the page, it is too late.
0
 
LVL 21

Assisted Solution

by:masterpass
masterpass earned 71 total points
ID: 33624002
0
 

Author Closing Comment

by:calypsoworld
ID: 33737792
Thank you!
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Entity Framework is a powerful tool to help you interact with the DataBase but still doesn't help much when we have a Stored Procedure that returns more than one resultset. The solution takes some of out-of-the-box thinking; read on!
This article explains how to reset the password of the sa account on a Microsoft SQL Server.  The steps in this article work in SQL 2005, 2008, 2008 R2, 2012, 2014 and 2016.
There's a multitude of different network monitoring solutions out there, and you're probably wondering what makes NetCrunch so special. It's completely agentless, but does let you create an agent, if you desire. It offers powerful scalability …
Visualize your data even better in Access queries. Given a date and a value, this lesson shows how to compare that value with the previous value, calculate the difference, and display a circle if the value is the same, an up triangle if it increased…

631 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question