Cross-Site Scripting and SQL Code Injection

Published: September 17, 2002

Host MS_Stephen_D:
Welcome to today's Cross-Site Scripting and SQL Code Injection chat. I will ask the hosts to introduce themselves.

Host Guest_Erik_MS:
Hi, I'm Erik Olson. I'm a program manager on the ASP.NET team.

Host Guest_David_MS:
Hi, I'm David Ross. I'm a member of the Secure Windows Initiative Attack Team at Microsoft and I've been involved with client-side security for some time.

Host Guest_Tom_MS:
Hi! Im Tom Gallagher from the Microsoft Office security team.

Host Guest_Andres_MS:
Hi, i'm Andres De Vivanco, member of Secure Windows Initiative. I look at SQL related vulnerabilities.

Host Guest_PeterTorr_MS:
Hi, I'm from the Programmability team that builds all the script products for Microsoft (JScript, VBScript, WSH, JScript .NET, VSA, ...)

Host MS_Stephen_D:
And... I am Stephen Dybing, SQL Server Communities PM. Glad you all could make it today!

Host MS_Jerry_B:
Hi, I'm Jerry Bryant. Security Communities PM. Thanks for coming!

Host MS_Stephen_D:
The Input Room is where you can enter questions for our hosts today. We will read them and select questions to answer. The questions and answers will be posted in the Reading Room.

Host MS_Stephen_D:
Let's get started! Fire away with your questions for our hosts.

Host MS_Stephen_D:
Q: Adi: This is a question about the chat it self. Since English is not my native lagnuge, is it possible to get the transcript of the chat when it is over, so I'll be able to look it again?

Host MS_Stephen_D:
A: The transcript will be posted next week. If you look in the left nav, you'll see a link to chat transcripts.

Host Guest_David_MS:
Q: Roger: how do we write code to prevent cross-scripting?

Host Guest_David_MS:
A: Right now it's a bit of an art. You want to be filtering for characters as input as well as output, but a good list of exactly what's "OK" is hard to find. www.owasp.org/ has a lot of good advice and I can go into detail on some of this if you'd like.

Host Guest_David_MS:
Q: Cipher24: What can someone tell me about filtering browswer output as a means of controlling user provided data

Host Guest_David_MS:
Q: Cipher24: The site I am currently maintaining already uses extensive filtering of all input provided by users. The problem which my team has run into involves languages which use double byte characters.

Host Guest_David_MS:
Q: Cipher24: as a means of not removing legit characters, and valuable user data - the idea of filtering the output has been brought up.

Host Guest_David_MS:
A: If what you have is really a blob of potentially malicious HTML (HTML plus script?), and just want to blast it out to a page, you may want to consider using a frame/iframe with the security=restricted attribute.

Host Guest_David_MS:
A: Although you may require a solution that's a bit more cross-platform.

Host Guest_Tom_MS:
Q: XSS : What development tools, besides things like Server.HtmlEncode (which doesn't catch all XSS attacks), is Microsoft providing to help prevent these types of attacks?

Host Guest_Tom_MS:
A: Preventing all XSS attacks is a difficult problem. As a developer you need to think carefully about what you are sending where that appears in the resulting document. There are many attacks which don’t need angle brackets and double quotes so HTML encoding does help there. URL Scan may help a little with filtering out suspicious looking characters.

Host Guest_David_MS:
A: More on XSS's question: You may also want to look into the new HTTPOnly cookies feature in .NET Server and XP SP1.

Host Guest_David_MS:
A: More on XSS's question: The HTTPOnly cookies feature allows servers to specify that specific cookies are not to be made available to the object model on a page (document.cookie).

Host Guest_David_MS:
A: More on XSS's question: This can mitigate the threat of cookie stealing if an XSS hole is found in your site.

Host Guest_David_MS:
A: More on XSS's question: although it doesn't prevent other types of attacks that may be possible given an XSS hole (spoofing, etc.)

Host Guest_Erik_MS:
A: More on that question. As Tom mentioned, it's very hard to do this generally. Future releases of ASP.NET will offer some help by detecting dangerous constructs in incoming data and throwing an exception when they're found. The real intent of this feature is to motivate developers to secure their code by rigorously validating and/or encoding data as appropriate and then disabling the feature. You can do a much better job of validating data when you know what the data is and how it's going to be used<end>

Host Guest_David_MS:
A: More information on HTTP Only cookies is available here:
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/httponly_cookies.asp

Host MS_Jerry_B:
A: This article has links to more detailed information as well.

Host Guest_Andres_MS:
Adi: do you have any specific question about SQL injection

Host Guest_David_MS:
A: Also, WSC v2 by Michael Howard and David LeBlanc will have a lot of great information on XSS and SQL injection:

Host Guest_David_MS:
A: http://www.amazon.com/exec/obidos/tg/detail/-/0735617228/qid=1032283640/sr=8-2/ref=sr_8_2/104-3901087-4034345?v=glance&s=books&n=507846

Host Guest_David_MS:
A: And as I mentioned above, OWASP. (www.owasp.org) An excellent resource.

Host Guest_Andres_MS:
Q: Adi: Not really. I read a lot about it. I have to give a presentation about it. I'm trying to get some more information. I'm sure that there are lots of things that I didn't think about, and I'm hoping to get some ideas here. The ideas should also

Host Guest_Andres_MS:
Q: Adi: help me improve protection on my servers.

Host Guest_Andres_MS:
A: Adi: The best practice against SQL injection attacks is to write stored procedures instead of building your SQL queries directly from the users' input.

Host Guest_Andres_MS:
A: Adi: Then pass input values to your stored procedures where more validation can be made.

Host Guest_David_MS:
Q: GTodd: I've read more about SQL injection (David Litchfield's stuff) than XSS. Can someone clue me in on what XSS is/means?

Host Guest_David_MS:
A: XSS describes a type of attack where a server replays information from a client when that data may have originated from a malicious source.

Host Guest_David_MS:
A: It's easiest to think about it in terms of the attack scenario. 1) Victim browses to a malcious web page.

Host Guest_David_MS:
A: 2) Malicious web page navigates (or submits a form) to a Victim server. (There are really two victims in an XSS attack)

Host Guest_David_MS:
A: 3) Victim Client receives a web page generated by the Victim Server containing malicious client-side script.

Host Guest_David_MS:
A: 4) Malicious client-side script executes on the client side in the security context of the Victim Server.

Host Guest_David_MS:
A:Another way to think about it is to look at an XSS exploit URL and imagine what happens. If I have a page on my server that responds to http://www.myserver.com/whatever.asp?name=Dave with a web page that says "Hello Dave", what do you think will happen if I navigate to an URL like: http://www.myserver.com/whatever.asp?name=<script>alert(document.cookie)</script>

Host Guest_David_MS:
A: The cookie will be myserver.com's cookie, but the script will have come from whoever created the URL.

Host Guest_David_MS:
A: And the script could have just as easily sent the cookie to some other server by way of page navigation.

Host Guest_Tom_MS:
Q: XSS : How much do programmers on client platforms need to worry about cross site scripting?

Host Guest_Tom_MS:
A: Client programmers definitely need to worry about cross-site scripting (XSS). Often client applications either host Internet Explorers rendering engine (Trident - MSHTML.DLL) and run in the My Computer zone or have script in local html files (files on the local hard disk). There is a great danger that an attacker can get code into the My Computer zone in both of these cases. What may not be obvious is that a document on your hard disk that takes input through the URL (hash, search string, etc) and does a document.write or other output can lead to a XSS vulnerability. This XSS vulnerability would allow the attacker to run code in the My Computer zone. In Windows XP SP1 Internet Explorer blocks redirection from the Internet zone to the My Computer zone to help mitigate XSS in local content.

Host MS_Stephen_D:
Q: XSS: Does Microsoft have plans for a "magic quotes" feature to help combat SQL Injection?

Host MS_Stephen_D:
A: We are looking into mechanisms by which we can further aid application developers in preventing SQL injection attacks. In some sense these mechanisms already exist in sp_executesql and QUOTENAME. But the real mitigation is in proper validation of user input at the application level. The further support solutions to aid in this is not decided completely yet

Host Guest_PeterTorr_MS:
Q: JimG : I'm using FrontPage to create a form that will be sent to an email address once submitted. Do I need to worry about XSS?

Host Guest_PeterTorr_MS:
A: The FrontPage bots should cover most of the issues for you if you just have an e-mail form.

Host Guest_PeterTorr_MS:
A: The main problems are when the form is submitted to a server which then re-sends the information

Host Guest_PeterTorr_MS:
A: back to the client, containing the malformed data.

Host Guest_PeterTorr_MS:
A: Nevertheless, if you have an older e-mail client or you do not run in the "Restricted" zone,

Host Guest_PeterTorr_MS:
A: it may be possible for people to e-mail you malicious content via the form. (Then again, they

Host Guest_PeterTorr_MS:
A: could just e-mail you directly, although that may reveal their identity).

Host Guest_Andres_MS:
Q: GTodd: I've seen suggestions that dropping "dangerous" stored procedures is a good way to reduce the danger posed by SQL injection. Is there any downside to this approach?

Host Guest_Andres_MS:
A: GTodd: Before you drop any SPs, you need to make sure you don't have any features that invoke the SP's you're dropping.

Host Guest_Andres_MS:
A: GTodd: For instance, if you drop xp_cmdshell, replication will stop working.

Host Guest_Andres_MS:
A: GTodd: Most SP's have good permission checks and if your clients log in using low privileged accounts you should be fine.

Host Guest_PeterTorr_MS:
Q: Adi: What is "magic quotes"?

Host Guest_PeterTorr_MS:
A: It is an option in Perl to automatically escape quotes in posted form data. There is some info at http://www.onlamp.com/pub/a/php/2001/02/15/php_admin.html

Host Guest_PeterTorr_MS:
Q: Teckno : Is it possible to share a directory with read and write permissions only? The idea is to limit users from being able to copy files off of a server

Host Guest_PeterTorr_MS:
A: If a user has read permission to your server, that means they can read the data and hence copy it.

Host Guest_PeterTorr_MS:
A: The only way to stop people copying it is to not let them read it in the first place.

Host Guest_David_MS:
Q: GTodd: XSS sounds very much like a client-side issue. Is there anything an administrator can do to prevent his/her server (or cookies) from participating in such an attack?

Host Guest_David_MS:
A: It can be argued both ways I think. On one hand you can say that only the client knows what it might interpret as script. This is a valid point.

Host Guest_David_MS:
A: On the other hand, servers must take some responsibility for content displayed in their security context.

Host Guest_David_MS:
A: In terms of what servers can do, best practices state that you should be filtering input and/or output.

Host Guest_David_MS:
A: Then there are also secondary things you can do such as use HTTPOnly cookies and forcing the codepage to something known.

Host Guest_David_MS:
A: But really the most important thing to do is server-side filtering, specifically allowing reasonable characters and denying everything else.

Host Guest_Tom_MS:
Q: JimG : What about other FP components like the send to database? Does FP protect me or do I need to do checks?

Host Guest_Tom_MS:
A: If you are using the wizard/bots in FrontPage, you should be safe because the SQL queries FrontPage makes are safe. If you write your own custom code inside of FrontPage, you are on your own.

Host MS_Stephen_D:
Our chat is about to end. Does anybody have any last minute questions?

Host MS_Stephen_D:
Thanks for joining us today! You've asked some great questions but unfortunately, it's time to go.

Host Guest_David_MS:
Thank you!

Host Guest_Erik_MS:
Thanks for attending!

Host Guest_Andres_MS:
thanks, see you next time!

Host Guest_Tom_MS:
Thanks. Have fun securing your apps.

Host MS_Jerry_B:
Please post follow up questions in our public newsgroups:

Host MS_Jerry_B:
http://www.microsoft.com/technet/community/newsgroups/security/default.mspx

Host MS_Jerry_B:
Or:

Host MS_Jerry_B:
news://msnews.microsoft.com for OE users.

Host MS_Jerry_B:
Thanks!