is it possible to hide windows taskbar during page load of an aspx page?
No. There used to be such option in IE, but as it was abused by malware (e.g. it hid the real taskbar and pretended there was a virus on the computer, then scared the user into downloading the real virus), it was removed.
In general, the code inside the browser has no business messing with anything outside the browser, for security reasons.
If you have control over the clients' computers (e.g. for an internal application that will be used from specific computers) and you know which browser(s) will be used, you could write a browser plugin (or an extension, in case of Firefox/Chrome/Opera) and install it on those computers - these have a much higher privileges of access to the rest of the OS, almost like normal processes.
No it is not possible without using some proprietary plugin inside the browser.
Related
I am trying to restrict the user from downloading the page as .html or .aspx file from browser.
Or is there a way to change the content of file if its downloaded?
This is a complex area, with lots of moving parts. The short answer is "there is no way to do this with 100% success; there are a few things you can do which make it harder".
Firstly, you can include JavaScript to disable the right click context menu. This doesn't stop Ctrl+S, but might discourage casual attempts.
Secondly, you can use DRM in the browser (though this is primarily aimed at protecting media content. As browser support is all over the show, this isn't realistic right now.
Thirdly, you could write your site as a single page web application, and build some degree of authentication into the "retrieve content" logic. This way, saving the page to disk wouldn't bring the content along, just the "page furniture". However, any mechanism you include to only download content when you think you should is likely to be easily subverted by anyone who is moderately motivated.
Also, any steps you take to stop people persisting your pages locally are likely to break the caching mechanisms on which the internet depends for performance, so your site would likely be dramatically slower.
No you can't stop them.
Consider how the web actually works here: once the user has visited your website and loaded your page into their browser, they have already downloaded it - the web page was transmitted from your server to their computer and appeared on their screen.
All they have to do then is click the Save button to keep it permanently on their disk. That doesn't involve downloading it again, it just copies the page data from a temporary folder to a permanent one. Of course it's also possible for people to use another HTTP client (i.e. not a browser, but maybe an existing program, or some code they wrote themselves) to visit the URL of your page and save the returned contents.
It's not clear what problem think you would solve by stopping people from saving pages. Saving the page is something done within the browser - you as a site developer don't control the user's browser, so you can't prevent that. And if you stop them from downloading your page in the first place then - by definition - you also stop them from using your website...which kind of defeats the point of having one :-).
If you've got some sort of worry about security, you'll have to clarify exactly what you are concerned about, and maybe you can get advice about a sensible way to deal with it.
Good day.
So, here is my issue.
I'm currently using sharepoint 2010 for web applications, I am supposed to display pdf as part of a web page. Currently, the browser tends to download the pdf file instead of displaying it.
Content-disposition is already set to inline.
I've also used iframe, and src is pointing to custom httpHandler.
I've already added "application/pdf" MIME type in the list of AllowedInlineDownloadedMimeTypes as per the advice in this link http://www.pdfshareforms.com/sharepoint-2010-and-pdf-integration-series-part-1/.
However, the application still failed to display it, and it prompts the user to download the file instead.
I'm using mozilla firefox v12 and ie8 to test the application, they both exhibit the same behavior.
What else is missing? Thank you.
It's important to remember that not all browsers, especially older ones like Internet Explorer 8, have the ability to render PDF content inline. In these older browsers, this was generally accomplished through plug-ins like Adobe Reader or Foxit being installed on the client machine.
Basically, if you are using an older browser, your users will likely need one of these (or a similar) plug-in installed. Otherwise when the browser encounters a PDF file, it will serve it to the user, as it doesn't really know how to deal with it.
There is also a chance that this could be a permissions / settings issue similar to the one addressed in this related question. You may want to review over some of the discussions within that thread as well as this Sharepoint 2010 one, which details a a setting called "Browser File Handling" and how it's default value of "strict" can affect how PDFs and other files are accessed.
He came across the solution while looking at the "Web Application General Settings". There is a setting called Browser File Handling and by default it is set to strict.
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.
I have a hyperlink to an executable like so: Run Now
I'm trying to make the download dialog box appear without the save function as it is to only run only on the user's computer.
Is there any way to manipulate the file download dialog box?
FYI: Running on Windows Server '03' - IIS.
Please no suggestions for a WCF program.
Okay I found it for anyone stumbling upon this conundrum in the future.
Add the following tag to your head section: <meta name="DownloadOptions" content="nosave" /> and the file download dialog box will not display the "save" option.
For the user to not open/run but save replace "nosave" with "noopen"
Not unless you have some control over a user's machine. If your application can run on limited resources, you might want to consider doing it in Silverlight.
IMO, having a website launching an executable is a pretty bad idea.... even worst if that website is open to the general public (not on intranet). I don't know what that app is doing but it sure is NOT, 1) cross browser, 2) cross platform, and 3) safe for your users.
If you are on intranet, you might get away with giving the full server path (on a shared drive) to the executable and change security settings on your in-house machines.
Other than that, you won't succeed in a open environment such as the Internet.
From your comments, if the user downloading the file is the issue, then there's no way to get around it, as they have to download the file in order to be able to run it.
There's any number of ways to get around whatever you could manage in browser, from proxies like Fiddler intercepting the data, or lower level things like packet sniffing. Or even simply going into the browser's temp/cache folder and copying the file out once it's running.
You could probably get around most laymen by having a program that they can download that registers a file extension with Windows. Then the file downloaded from this site would have the URL of the actual data obfuscated somehow (crypto/encoding/ROT-13/etc). The app would then go and grab the file. The initial program could even have whatever functionality provided by what you want to download, but it needs the downloaded key.
But this is moving into the area of DRM and security by obscurity. If an attacker wants your file, and it's on the Internet, they will get the file.
I have a Web Application (ASP.NET C# for .NET 3.5) that uses the Session object to store, amount little things the debug information so when things go wrong, this is the first place to go.
The process is simple actually,
no matter what browser (except IE), when I navigate to a page, in the Debug Log I have data, just like the one show below
alt text http://www.balexandre.com/temp/2010-04-14_1048.png
problem is that in Internet Explorer, the Debug Log is always blank (blank as no information, not no html code)
alt text http://www.balexandre.com/temp/2010-04-14_1051.png
What can I do?
I tried several Security settings of IE8:
add the site (machine name) to Trusted Sites
disable Protect Mode
set Local intranet security level to LOW
set Accept All Cookies under Privacy
checked the Allow Active Content under Advanced tab
I really don't know what more can I do :-(
Any help is greatly appreciated!
You could try using Fiddler - a web debugging proxy - to check traffic between IE and your site. Also, if you can, try other versions of IE on different machines/networks to see if it's a global problem, or just related to one browser. And don't forget you can hit F12 to enable developer console in IE.