snarf
Posts: 14
|
| Posted: 07/10/2004, 1:42 PM |
|
A common security issue with applications is cross-site scripting. The basic idea is that you stick some script code into an application field, post it to the database, and when an unwary user retrieves the content -- BOOM, the script runs on their browser and does bad things. Hackers abuse chat boards, forums, and other public places with this kind of attack. More adept and focused black-hats (some professional) can use this technique to help them gain unfair competitive advantages, steal proprietary information, etc. Obviously something you want to prevent.
More at: http://www.google.com/search?hl=en&ie=UTF-8&q=cross+site+scripting
Now the good news. CCS appears to have a feature that can help prevent this weakness from creeping into your application. When you set up a control on a form or page, you are offered a property named "CONTENT".
If this property is set to "Text", some or all of the malicous characters are presented to the browser in a format that prevents them from being processed as a script.
On the other hand, if this property is set to "HTML", then the script will be presented to the browser in a format that it will run... meaning if someone so chose, they could pop a script into that field and expolit your xross-site scripting hole.
Try it yourself. Put this string into a text field (i.e. a field for name or URL) exactly as it appears here:
<script>window.open('http://www.securitymethods.com');</script>
Now set the Content property of the field in question to "HTML", publish, and check the page where the content would appear. Set the Content property back to "Text" and you should see the script itself show up.
You can never say with 100% certainty that any feature will stop 100% of all cross-site scripting weaknesses, but this one sure appears to knock of a healthy chunk. If you're really worried about it, Google around and learn how to write a custom input handler that strips or escapes out all characters that could be used for cross-site scripting.
If you are actually using fields that require display as HTML, you may want to seriously consider stripping out any script tags that might get served using a 'Before Show' or related event trigger. Even better would be stripping them out on the way in using a 'Before Insert' event, that way there are no land-mines laying around for the next webmaster to step on.
Just to demonstrate how sneaky cross-site scripting can be, here's another little nasty script that hides itself. Let's say that you have a "name" field... you drop this script in there, and not only does the window open (think a window of size 0,0 that opens www.uberhacker.com/gotcha.php) but it also writes a name where the name should be. Unless you look at the HTML, you would never know a script is in there. Play with it.
<script>window.open('http://www.securitymethods.com');document.write('John Smith');</script>
___________________________
Constructive comments, criticisms, etc. welcome. Yes! insight would be particularly appreciated.
|
 |
 |
aradi
Posts: 66
|
| Posted: 07/10/2004, 2:01 PM |
|
Great article, thanks for the insight. very usefull.
|
|
|
|
peterr
Posts: 5971
|
| Posted: 07/10/2004, 3:18 PM |
|
Yes, we were considering making the Content property equal to HTML by default, but we backed off for security reasons.
The actual problem though is that almost no security is sufficient to protect a system and there is no such thing as a secure Website or Web server. Various security competitions were won by hackers who proved that they can break into almost any type of system. Many Portals and Ecommerce sites are releasing patches on ongoing basis that fix one security issue after another. Many companies employ security consultants or full-time people responsible for system security (could be included in the responsibilities of system administrators).
The cross-site scripting related problems (CSRF, XSS) go even beyond your Website. You can simply receive an email from someone that contains such "image":
<img src="YourWebsite.com/SomePHPprogram.php">
The problem with this is that your email client will try to display the image, but in fact it will run a PHP program on your Web server executed by you - the administrator, if you are logged in to your Website at that time. Therefore if someone knows how to execute something dangerous on your Website they can simply force you to execute it even without your knowledge.
Because of this, an Open Source developer responsible for the security of a popular portal told us that he no longer believes that their software can be fully protected since everyone can analyze the Open Source code and find some way to execute some administration links that can perform dangerous actions. The only protection would be to move the administration section of specific site to a different unknown location and/or implement custom protection, so that no one knows what, where & how to execute to access the administration. This is a type of security by obscurity.
Thus if you're not selling your application as Open Source to others then it is automatically obscured and not everyone knows how to access the administration, therefore cannot force you to execute dangerous links. But some people criticize security by obscurity and say that when everyone has access to the source code then together they can find more problems and fix them. Well, you decide what may be better.
But the lack of perfect solution for protecting Websites of course doesn't mean that you should do nothing about your application security.
Without getting into complexities of scripting vulnerabilities, you can work with your system administrator to protect the system as a whole, not just the Website scripts. You can actually bypass some of the scripting vulnerability concerns by doing other things to protect a Website.
For example:
- Allow access to your Website or the administration section only from certain IPs. That way even if someone obtains your administration password, they shouldn't be able to login from their own computer.
- The method that works best for us is custom monitoring of the server logging (easier to do on Linux) where we are notified by email or pager if someone executes a URL that contains our database name or other suspicious keywords. This way even if I execute something suspicious on our Website, then I and several key people will be immediately notified about it.
From scripting side (PHP, ASP, etc.) you can use custom code to verify that the page is submitted from your Web server and not from someone's local machine. Check that the submitted values are not outside of allowed ranges (especially when using hidden fields). Check if the currently logged-in user should be allowed to view specific record. Parse the HTML and do not allow certain HTML content as snarf noted, etc.
I'd even say that the more experience you have and the better you know your application and the database, the better you will understand what and how needs to be protected. There may be no universal method that can solve every security need.
We too plan to take another look at CCS security in the future and surely will come up with at least couple additional solutions for improving it. But the best solutions may require your own understanding of what and how needs to be protected, and can be implemented already via custom code, or even outside of the Web application as described here.
Comments are welcome.
_________________
Peter R.
YesSoftware Forums Moderator
For product support please visit http://support.yessoftware.com |
|
|
|
|
