Solved

XSS and SQL Injection attacks

Posted on 2010-09-07
10
646 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
Salesforce Made Easy to Use

On-screen guidance at the moment of need enables you & your employees to focus on the core, you can now boost your adoption rates swiftly and simply with one easy tool.

 

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

Online Training Solution

Drastically shorten your training time with WalkMe's advanced online training solution that Guides your trainees to action. Forget about retraining and skyrocket knowledge retention rates.

Question has a verified solution.

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

How to leverage one TLS certificate to encrypt Microsoft SQL traffic and Remote Desktop Services, versus creating multiple tickets for the same server.
Ever needed a SQL 2008 Database replicated/mirrored/log shipped on another server but you can't take the downtime inflicted by initial snapshot or disconnect while T-logs are restored or mirror applied? You can use SQL Server Initialize from Backup…
I've attached the XLSM Excel spreadsheet I used in the video and also text files containing the macros used below. https://filedb.experts-exchange.com/incoming/2017/03_w12/1151775/Permutations.txt https://filedb.experts-exchange.com/incoming/201…

710 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