I have a website with a flex application. The flex application has no user input - except for clicks for navigation. The website also uses no scripting language - i.e. no php, asp, jsp or cfm.
The website just consists of one page which contains the flash file for the flex application. The source code of this page is here: http://pastebin.com/n5b4RxqT
I have been advised (by a software program used by my client) that this website is vulnerable to a reflective type XSS attack and have been advised to 'sanitize' all user input.
I am a noob with respect to XSS and would respectfully like to ask that AFAIK there is no user input. What should I sanitize and how?
Thanks in advance
Using AC_OETags is the old way of doing things and is deprecated. What you want to do is use SWFObject which is now the default in Flash Builder 4.
Related
I'm trying to write an AIR application to be deployed on a mobile device.
I have an HTTPS website that I go to and log in using a browser. I can view things in my account, etc.
I want to use my AIR app instead of the HTTPS website. Can I "wrap" or "skin" an html site using AIR?
So I'm looking at StageWebView, URLRequest, URLLoader.
I need to POST things like username, password, and other things.
How can I do it?
See ExternalInterface on AS3 reference that you can use to call Javascript-functions on your site.
You can show HTML content with mx:HTML
If all you need to do is POST or GET, look into HTTPService
You might wanna have a look at the StageWebViewBridge, it has some extended features compared to the default StageWebView
http://code.google.com/p/stagewebviewbridge/
We wanted to use it in a project but ended up in implementing the URL based communication on our own. BUt you should give it a try, mabye it works for you.
The reason why I ask is that I'm telling a vendor of ours they have to use the MS AntiXSS library with the ASP.NET UI components they make, but they also work with Flex to build Flash based UIs - and I was wondering if there's an equivalent for Flash (assuming it's vunerable).
If I understand correctly...
ASP.NEt is used to make web pages, and all UI Components they make will be running in a browser as HTML / JavaScript. Is that correct?
If that is the case, I can understand why preventing cross site scripting would be important in that case.
With Flex (which runs in the Flash Player), everything is compiled down into a binary file, called a SWF. Most of the time, the SWF runs inside the Flash Player, which runs in the browser as a plugin. There would be no way to hack an individual Flex component using XSS.
I don't believe the code you write needs to be protected from cross site scripting. Your biggest fear is player vulnerabilities, which you don't have much control over.
None of this should be a reason not to validate user input.
The short answer is: the Flash player has a lot of features in place to prevent XSS attacks, but they're built in to the player itself, so there isn't any particular library you need to use. If you don't call any security-related APIs, and don't put config files on your server, then security-wise, you are already using the most restrictive settings available. (Assuming you also pay attention to how you make use of user input.)
More generally, APIs that have the potential to lead to XSS vulnerabilities are as a rule disabled in XSS situations unless you actively enable them. For example, if an HTML page on your site loads in a flash file from another site, and that flash content tries to, say, make javascript calls into your page, those calls will be blocked by default unless you allow them. Similarly, if flash content on your site loads in components from another site, those components will not be able to introspect into their parent unless you call APIs to allow them to. There are also various restrictions on what happens when another site tries to load in Flash content from your site without your having allowed it.
For all the details, I highly recommend this excellent overview:
Creating more secure SWF web applications
With all that said, since you also asked about sanitizing user inputs, it's worth noting that since AS3 has no equivalent of an eval command there is never any question of user input being executed as script. However, any user input that relates to content being loaded could be a vector of XSS attack. (For example, if you append a user-input string to a URL you then load, the user could cause your site to load in their malicious SWF.) But such a case is no different from a situation where you load in a benign 3rd-party SWF, and someone later replaces it with malicious content. Hence in context of Flash, protecting against XSS attacks is not so much about sanitizing user input as it is about making sure that externally loaded contents are not granted permission to run as if they were locally trusted.
And further, since it's often useful or necessary to relax the default restrictions if you want to do something interesting with 3rd-party content (like flash avatars, components, or even banner ads), in those situations it's important for the site admin to understand what they are allowing, and how to prevent the relaxed restrictions from exposing a vulnerability.
This is a pretty basic question.
Since browsers have a culture setting that the web app uses to decide which locale to use, should I still have a "language" button for users to be able to override the culture?
Why or Why Not?
To me it doesn't make sense to have a button there if the user had already set their language in their system.
Yes, you should.
One of the reasons outlined on the ASP.NET Localisation page is that a user may have a preference for reading certain types of websites in a specific language (i.e. technical websites in English). This is a good reason.
There are other reasons as well (i.e. the translation may not be great, a different user than typical is using the given computer, etc, etc).
I've found that some of my ASP.Net web apps prompt the browser to load plugins that I'm not explicitely using and certainly haven't deliberately referenced in the project settings.
Two that come to mind are for MS MediaPlayer and the "SVG Viewer for Netscape".
The only commonality I've determined so far is that the two sites/apps affected both use Master pages (nested in some cases).
We don't use SVG file types (just the normal mix of jpg/gif/png) and no video/audio (not yet anyway).
Can anyone provide a hint as to where the references for these might be creeping in? e.g. Is it a server-level include? Or a .Net runtime default when using master pages?
Does anyone else even experience this, or is it just me?
No urgency, I'd just like to remove it if possible.
Thanks.
Al
If you look at the page source in your browser, you should see what's in the page that requires a plugin. If you load external Javascript, you will have to look at that too. Do you have ads on the site that include 3rd party code?
Is there a way to programmatically set the name of a file to be uploaded from a web page? I suspect that browser security restrictions make this impossible, but I'm hoping someone will prove me wrong.
I have a web application that needs to let the administrator upload HTML. The admin selects the HTML file, then the app uploads that file, plus figures out all the supporting files (images, stylesheet, etc) and uploads them too. There doesn't seem to be a way to programmatically upload the supporting files from a web page, since the user has to specify each file explicitly.
Currently I have a separate Windows app to do this, but it would be ideal to have this functionality integrated with the rest of the app. My back end is ASP.NET with C#.
There is no way to programatically grab files from a user's computer via the browser. This would be a security violation if a website could just grab things.
Yes you can (in modern browsers)...
You can get and set the value of HTMLInputElement.files.
See this answer.
No, you cannot do this without a client-side application or special plug-in.
Browser security doesn't allow the server to obtain information about the hard drive contents of the client.
You may be able to do this using some form of browser plug-in. This is more work for you (and there are potential security implications for this beyond those found when you just have users run your app). However, it may prevent a more integrated experience for your users. I'd hesitate to eliminate the application completely, though. Browser compatibility issues are common.