My requirement is to secure static files so that it cannot be accessed from url.I placed those css and js files inside WEB-INF but now i am not being able to access it from my jsp page.I tried following.
webpages|
WEB-INF|
img|
batman.jpg
test.jsp
now i tried it to acess from jsp page as <img src="../WEB-INF/img/batman.jpg"/> as well as
<img src="img/batman.jpg"/>
but none works.test.jsp is placed outside of web-inf and placing it inside of web-inf is currently not an option for me.I am not using Spring Framework just basic jsp and servlet and i want solution for them.Thnks guys.
As EJP rightfully stated, if you want to embed an image in your page you are bound to access it via an URL. Think of it like that: even though you manage to restrict access to image source (though you won't be able to), user will be able to copy it off the screen, which violates your assumption and which is left to the client.
But of course there are some workarounds to achieve 'second-best' functionality to your problem. I'll list some of them that come to mind:
Put a watermark. Place your images in public folders, but modify the content by providing a watermark to every sensible image. This way you don't restrict the access, but lower the probability of fraudulent behavior after images' exposure;
Modify filenames. You could modify filenames of your images and keep correspondence between 'real' name and artificial name on the server, for example, in a database. This way you'll significantly lower the risk of mass leakage of secured images;
Introduce client side restrictions. You can introduce client side restrictions on your image elements, like disallowing appearance of popup menus, showing full images in dialogs that force user into thinking that image is protected, etc. Of course, anyone with little browser experience will be able to get the content, but basic users won't.
I think that there are many more ways to lower the probability of inappropriate behaviour, but none of these ways reduce that probability to zero. So, you're basically left with opening access to your images, while you may make malicious work harder by putting a watermark on all of your sensible images.
Your requirements are mutually contradictory. You are making a resource inaccessible via a URL and then attempting to access it via a URL.
Make up your mind.
Related
I'm building an angular 2 website where only authenticated users can access content. Some of this content is peoples photos, to which access must be restricted to authenticated users only. Furthermore, these images should be delivered in an optimized fashion depending upon the device calling them; for example, a retina mobile screen, or an old-fashioned laptop.
Any ideas about how (or the best practices) to achieve this correctly?
We do something like this, but we don't use angular for it, we use css to determine which images to display. Separate classes with the images attached for them based on viewports. Are you wanting a angular 2 specific answer? Or will the viewports displaying different images work?
I know its a security feature in IE to not allow scripts to interact past frame tags/objects but is there a way around this?
I am using a program to interact with the IE COM interface.
For example if I were to have an tag and I wanted to use the $tagobject.innerhtml to retrieve the html inside the frame tag, what is the best way of going that this?
Native code running at full trust (e.g. an IE plugin) can interact with any document loaded in the browser. You're correct to note that interacting with subframes that are from an origin different than the top-level page is blocked by security policy when accessed in the "simple" way. But native code can circumvent that.
This support article shows how to enumerate the contents of all frames, regardless of their origin. The basic idea is that you cast the top-level document to an IOleContainer and then enumerate its children, which bypasses the security check.
I want to know if there are advantages to keeping the extension of an image (on the client side, because on server side (linux), i do not see the benefits, knowing that the extension isn''t important).
Is it better to have <img src="/a" /> or <img src="/a.jpg" /> ?
So, store in server images with extension ?
Information: The images are photographs of the users. Names of the image is complex.
I'm thinking to keep extension, because if the user save the image, they will have extension.
But keep extension is a little more complicated for development.
And it can be advantage to stay with no extension?
Typically, the extension is how the web server determines the MIME type for the file, which is how the browser knows it's an image and not text or arbitrary binary data or something else.
So, typically, you'd want to keep the extension just for that reason. There may be unusual situations where that may not be true, but in a typical web server serving files right off the filesystem, that's the case.
If you don't need the extension on the server side because you are sending the correct MIME type regardless of extension, then yeah, the only obvious advantage would be for situations where the user would want to save the image and the browser or OS isn't smart enough to do the right thing with the image without an extension. In this day and age, I have no idea how common that situation is but it is certainly less common than it used to be.
Personally, I'd be disinclined to worry about it if it will complicate development for you (especially if it's something you can always go back and do if you find out that you actually do need it for some reason). What I would ponder, though, is if there is something that needs to be improved in the application architecture if preserving the file extension is a big headache. It seems like that shouldn't be a big deal one way or the other. Of course, I say that without knowing the particulars of your situation; I'm just speaking in generalities.
Not using extension should be fine as long as you send the correct MIME types. Browsers automatically add extensions if required. (Prove: Your Gravatar picture: http://www.gravatar.com/avatar/f1f8a3382d2946bd526dd629eaa29b2b?s=32&d=identicon&r=PG)
Basically you can use any extension as long as the MIME type is correct. If you serve your files statically using extension would be more convenient since most Webservers use extension-based MIME-type guessing. Serving from a database not using extensions could be more convenient...
We're using the Mantis bugtracker (version 1.1.8), which is based on PHP. To ease the workflow of adding bugs we'd like to add an option to paste screenshots from the clipboard directly into the 'new bug form'.
Screenshots make bugreports much more valuable for developers, so I'd like to make adding them as easy as possible. Preferably without using an external application, but right in the browser.
I've looked all over for a way to add this, but no luck. How do other people do this? Am I missing something obvious?
edit: The bugtracker is a private one, in a small company, so I'd be willing to accept the security risks that for example Java applets present.
There isn't really a way to do this short of using ActiveX, applet or Flash-type technology on the client. Even then, there are numerous security roadblocks. A browser has no easy way to convert stuff from the clipboard into a suitable format for upload to a website, and even if it did there would be security concerns. For example, malicious code in a page could copy sensitive information from your clipboard and send it to the page's site without you even knowing it was happening.
Update: There is a standalone screen capture utility which claims to work with Mantis (and a whole bunch of other bug-trackers). This is probably your best option.
There is a drag n drop image attacher Java applet for Atlassian Confluence which has the functionality you need. It only supports Confluence but as the sourcecode is freely available under BSD you should be able to customize it to your needs.
Forgot the link:
http://confluence.atlassian.com/display/CONFEXT/Drag+and+Drop+Image+Attacher+Plugin
I've managed to build my own solution that works quite well. It places a Java file upload applet on the pages where you'd want to attach a screenshot. The applet has two buttons:
'paste screenshot', which pastes an image from the clipboard into the applet
'upload screenshot', which uploads the pasted image to the /tmp dir on the Mantis server and uses a javascript callback to place the autogenerated filename of the uploaded image into a form field.
Once the form is submitted, a new function in Mantis uses the filename in the form field to move the image from /tmp to the final location and processes the image just like other attachments. If the form is never submitted the uploaded file remains in /tmp and will eventually be purged by the server.
It works well, but has one drawback that I cannot avoid: I'm using Java to get access to the client's clipboard, but that requires breaking the JVM sandbox. Apparently, this can be done if you digitally sign the applet, which requires a rather expensive yearly payment (something like $500) to a company like Verisign (currently free options like cacert.org are still limited in their usefulness).
Another way to allow Java applets access to the clipboard is to create a file called .java.policy in your home or profile directory. This file should contain the following (Replace the domain with the domain that hosts your Java applet):
grant codeBase "http://bugs.example.com/-" {
permission java.awt.AWTPermission "accessClipboard";
};
Thankfully the solution is cross-browser compatible since the JVM always checks the same file regardless of the browser used. Since my solution requires having this .java.policy file on each client computer I don't consider it ideal, but workable in a controlled company environment.
I looked in to this also. No real easy way, so instead I allowed them to upload an unlimited number of files and those files would then be "attached" to that bug. It actually turned out to be better because they can upload screenshot, spreadsheets, word docs, etc.
Like yours, this is an internal only site so security is light. I did this in ASP.Net, but the general idea is that when they are looking at a page for a bug they have an upload box. When they upload something I pre-append it with the bug id. So ScreenShot.jpg becomes 233_ScreenShot.jpg.
Also on that page is a grid (GridView) that is bound to all of the filenames in my upload directory that start with that bug id.
To see what this looks like click here.
For tech-oriented users, there's always to possibility of using Eclipse + Mylyn + Mylyn-Mantis connector.
Then uploading screeshots is very easy:
Screenshot upload http://img216.imageshack.us/img216/246/screenshotattachments1.png
I want to allow my users to embed their own Flash animations in their posts. Usually the actual file is hosted on some free image hosting site. I wouldn't actually load the flash unless the user clicked a button to play (so that nothing auto-plays on page load). I know people can make some really annoying crap in flash, but I can't find any information about potential serious damage a flash app could cause to the viewer.
Is it unsafe to embed just any flash file from the internets? If so, how can I let users embed innocent animations but still keep out the harmful apps?
edit:
From what I can gather, the most obvious threat is for actionscript to redirect you to a malicious site.
Adobe says you can set allowScriptAccess=never and allowNetworking=none and the swf should have no access to anything outside of itself. Will this solve all my problems?
Flash has some neat security measures in place. Allowing users to upload swf's to your site and embedding them is unsafe, you're basically setting yourself up for an XSS attack.
However, allowing them to hotlink should not be a problem. The swf will be locked to the domain that is hosting it and is not allowed calling url's outside of that space.
It will still be open to "evil links" (i'm sure theres a proper word for them), and by that I mean having regular links to yoursite.com/admin/deleteallpages.php which it tries to load "as" you. It will not however be able to use this data in any way, it'll basically be the same as a normal link, and I'd guess modern cms' are protected from that type of attacks.
You could get the same protection by hosting your flashes on a different subdomain, since flash considers this the same as a completely different domain.
When embedding SWFs from unknown sources, it is also best practice to throw a mask on the Loader so that the loaded SWF can't take over more screen real estate than expected.
Pseudo-code to do so:
var maskSpr : Sprite = new Sprite();
maskSpr.graphics.beginFill();
maskSpr.graphics.drawRect(0,0,safeWidth,safeHeight);
maskSpr.graphics.endFill();
myLdr.mask = maskSpr;
There is actually more than one option.
To be totally safe, set allowScriptAccess=never and allowNetworking=none and the swf will have no access to anything outside of itself.
NOTE: allowNetworking is only in Flash Player 9 (it was created in response to various myspace worms), so you'll need to use SWF Object to insure that only users with the right flash player version or better have the flash loaded.
If you want to enable things like youtube videos, though, you can't set allowNetworking to "none". Fortunately, there is an intermediate level of security for this field - "internal" which lets the SWF talk to its hosted domain.
Also note that you better not have a crossdomain.xml file on your site - read more about those dangers here and other places.
Here are some other sites that are mentioned by other answers that go into more detail:
http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps_04.html
http://blogs.adobe.com/stateofsecurity/2007/07/how_to_restrict_swf_content_fr_1.html
As an example Drupal has a scenario of how allowing flash content from users could be a security concern.
Adobe says you can set allowScriptAccess=never and allowNetworking=none and the swf should have no access to anything outside of itself. Although allowNetworking is only in Flash Player 9, so users with earlier versions of Flash would still be susceptible to some exploits.
Creating more secure SWF web applications : Security Controls Within the HTML Code
How to restrict SWF content from HTML
Yes, it's unsafe.
There's no easy way of allowing it. You could have a domain whitelist that allowed YouTube, Hulu, etc. through, but whitelisting is inherently painstaking - you'd be constantly updating.