Let's say I have a swf with a movie or something (it's a stream actually but it doesn't really matter).
I created a quite secure way to get to the page where it is displayed (as embed). The only problem is this:
How do I stop someone to view source or use something like Firebug and send the address of the file to somebody else.
I want them to see the result but not be able to send it to anyone else.
The platform for my site is LAMP.
You can't do this.
if you don't want the client to know something, the only option is to not tell it;
if you don't tell the client where the file is, he can't possibly view it.
What you should do instead, is to have some authentication and authorization in place, so that only authenticated and authorized users can access said address. That way users can share the address as they like, but unauthorized users can only get "Access denied" messages.
This does not prevent authorized users from downloading the file and hosting it somewhere else, though. If you don't trust them not to do this, don't authorize them.
I created a quite secure way to get to the page where it is displayed
intriguing. Please describe this secure way in detail.
If its secure in the sense that it authenticates and authorises the user, then it provides the security you ask about from the sharing of URLs.
You could implement a refer[r]er check to prevent users accessing the file directly.
$referer = $_SERVER['HTTP_REFERER'];
$components = parse_url($referer);
if ($components['host'] != "www.example.com") {
// User didn't access file from your site.
}
This can be circumvented by spoofing the referer header but should defeat casual users.
Naturally, this doesn't prevent someone downloading and re-hosting the file.
Related
I am developing a MERN app, where users share things with a link to access those things.
So these things get displayed to other users, and they can click on them, and they get redirected to that link.
This doesn't seem secure as some users can post things with malicious links.
Is there a way to verify that a link is secure and so validate the thing before it gets posted?
This isn't possible in an automated way. Links don't include any information about themselves other than the URL they point to.
You need a list of "malicious" URLs to compare against in order to achieve this. There are services that provide such databases. But this is a never-ending game of cat-mouse.
For example, if I have a malicious website, I don't have to share the URL to my website directly, I can use URL shortener service (bitly for example) that then redirects users. This way, I easily circumvented your protection.
That's the reason browsers have their own "malicious websites" list, since they have access to the final URL you're visiting.
In short: no, there's only limited protection you can offer.
The best you can do is warn the users they're leaving your site, like Discord or Facebook do (and they do that because they can't solve this problem either).
I'm trying to implement a GET method with Express in my nodeJs application.
I'd like to do something like this in order to display user data :
router.get("/user/:idUser", (req, res) => {
The user doesn't need to be authenticated in order to execute this code. However I don't want that anybody can execute this request with a user id of someone else. Because he could see data he's not supposed to see.
How could I proceed ? I thought about using some encryption process to have something like :
/user/PdfgdfJFDGTfrfgdsf
Your question isn't really making sense. You don't want authentication, but you only want a user to be able to view their own data so nobody else can view it.
The ONLY way to solve that is by using some form of authentication. The user has to prove to the server that they are allowed to view that data before the user renders the page for them.
Yes, you could obscure the URL (make it some mostly unguessable string of characters), but it's not clear what problem that is solving. The user themselves won't be able to remember it or type it so it would probably have to be a link in a web page and if it's a link in an unauthenticated web page, then anyone can get to it - thus defeating the purpose.
There are cases where temporary links (often done for privileged downloads) such as what you mention /user/PdfgdfJFDGTfrfgdsf are sent via an authenticated channel (either an authenticated webpage or sent to an email address known to belong to an authenticated user) and these links contain some unique and hard to guess code. The user can then click on that link (in authenticated webpage or in email) and access that resource without further authentication. In that case, the knowledge of the code in the URL is serving as a form of proof of authentication. Because URLs may be logged in service providers or corporate infrastructure and thus not remain entirely private, this technique has its limitations and is typically only used for short term (download this resource in the next 10 minutes) type of uses, not a long term substitute for authentication and not used for things that demand real security. You don't explain enough of your use case to know whether this is practical for your situation or not.
The user doesn't need to be authenticated in order to execute this code. However I don't want that anybody can execute this request with a user id of someone else. Because he could see data he's not supposed to see.
That's an inconsistent statement. You say "user doesn't need to be authenticated in order to execute this code" and then you say "I don't want that anybody can execute this request with a user id of someone else.". You can't have both. The user is either required to prove authorization or they aren't. Pick one. It can't be both.
you can use jwt for this and a auth middleware for this
upon decoding jwt token, you can implement logic to check if the decodedToken.user_id (given that you add user_id when encode token payload) is equal to the :idUser in route (or any kind of logic you want) there.
My web application displays some sensitive information to a logged in user. The user visits another site without explicitly logging out of my site first. How do I ensure that the other site can not access the sensitive information without accept from me or the user?
If for example my sensitive data is in JavaScript format, the other site can include it in a script tag and read the side effects. I could continue on building a blacklist, but I do not want to enumerate what is unsafe. I want to know what is safe, but I can not find any documentation of this.
UPDATE: In my example JavaScript from the victim site was executed on the attacker's site, not the other way around, which would have been Cross Site Scripting.
Another example is images, where any other site can read the width and height, but I don't think they can read the content, but they can display it.
A third example is that everything without an X-Frame-Options header can be loaded into an iframe, and from there it is possible to steal the data by tricking the user into doing drag-and-drop or copy-and-paste.
The key point of Cross Site Attack is to ensure that your input from user which is going to be displayed, is legal, not containing some scripts. You may stop it at the beginning.
If for example my sensitive data is in JavaScript format, the other site can include it in a script tag
Yep! So don't put it in JavaScript/JSONP format.
The usual fix for passing back JSON or JS code is to put something unexecutable at the front to cause a syntax error or a hang (for(;;); is popular). So including the resource as a <script> doesn't get the attacker anywhere. When you access it from your own site you can fetch it with an XMLHttpRequest and chop off the prefix before evaluating it.
(A workaround that doesn't work is checking window.location in the returned script: when you're being included in an attacker's page they have control of the JavaScript environment and could sabotage the built-in objects to do unexpected things.)
Since I did not get the answer I was looking for here, I asked in another forum an got the answer. It is here:
https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.security/9U6HTOh-p4g
I also found this page which answers my question:
http://code.google.com/p/browsersec/wiki/Part2#Life_outside_same-origin_rules
First of all like superpdm states, design your app from the ground up to ensure that either the sensitive information is not stored on the client side in the first place or that it is unintelligible to a malicious users.
Additionally, for items of data you don't have much control over, you can take advantage of inbuilt HTTP controls like HttpOnly that tries to ensure that client-side scripts will not have access to cookies like your session token and so forth. Setting httpOnly on your cookies will go a long way to ensure malicious vbscripts, javascripts etc will not read or modify your client-side tokens.
I think some confusion is still in our web-security knowledge world. You are afraid of Cross Site Request Forgery, and yet describing and looking for solution to Cross Site Scripting.
Cross Site Scripting is a vulnerability that allows malicious person to inject some unwanted content into your site. It may be some text, but it also may be some JS code or VB or Java Applet (I mentioned applets because they can be used to circumvent protection provided by the httpOnly flag). And thus if your aware user clicks on the malicious link he may get his data stolen. It depends on amount of sensitive data presented to the user. Clicking on a link is not only attack vector for XSS attack, If you present to users unfiltered contents provided by other users, someone may also inject some evil code and do some damage. He does not need to steal someone's cookie to get what he wants. And it has notnig to do with visiting other site while still being logged to your app. I recommend:XSS
Cross Site Request Forgery is a vulnerability that allows someone to construct specially crafted form and present it to Logged in user, user after submitting this form may execute operation in your app that he didin't intended. Operation may be transfer, password change, or user add. And this is the threat you are worried about, if user holds session with your app and visits site with such form which gets auto-submited with JS such request gets authenticated, and operation executed. And httpOnly will not protect from it because attacker does not need to access sessionId stored in cookies. I recommend: CSRF
I have a url to a search page (e.g. http://x.y.z/search?initialQuery=test). It isn't a webservice endpoint, its just a basic url (which goes through a Spring controller). There is no security around accessing page, you can enter the link in a browser and it will render results.
What I want is to find a way to prevent other sites from submitting requests to this url, unless they are specifically allowed.
I build a filter which would intercept all request to this page, and perform some validation. If validation failed then they would be redirected to another page.
The problem is what validation to perform... I tried using the referer field to see if the request was coming from an "allowed" site but I know the referer field isn't always populated and can easily be faked.
Is there a way to achieve this?
We also have IHS so if there is something that can be done in there either that would be great.
I'd suggest implementing some kind of system to allow users to log in if you really want to protect a page from being accessed.
You could try to detect the IP address of the incoming request, but I'd imaging that this can be spoofed quite easily.
Realistically, pages that are public are open to any kind of interrogation to the limits that you set. Perhaps limiting the data that the page returns is a more practical option?
This is the reason that website's like Facebook and Twitter implement oAuth to prevent resources from being accessed by unauthorised users.
How about you only run the result if the referring page has passed along a POST variable called "token" or something which has been set to a value that you give each app that's going to hit the search page. If you get a request for that page with a query string, but not POST value for "token", then you know its an unauthorized request and can handle it accordingly.
If you know the IPs of sites which can contact your service, you can put Apache as a proxy and use access control to permit/deny access to specific directories/urls.
I assume that you want to avoid having your site "scraped" by bots, but do want to allow humans to access your search page.
This is a fairly common requirement (google "anti scraping"). In ascending order of robustness (but descending order of user-friendliness):
block requests based on the HTTP headers (IP address, user agent, referrer).
implement some kind of CAPTCHA system
require users to log in before accessing the search URL
You may be able to buy some off-the-shelf wizardry that (claims to) do it all for you, but if your data is valuable enough, those who want it will hire mechanical turks to get it...
make a certification security.
u can make self signed certification using openssl or java keytool
and u will have to send a copy of certificate to ur client.
If this client will not have this certificate, It will not be able to call ur service.
And to make certificate enable in ur web container.I dont know bout other containers but
in Apache tomcat, u can do it in connector tag of ur server.xml
I'm building a Flex client against a Struts backend and I have to find a way to transmit the session token without relying on cookies, because I can't use cookies in a Flash movie.
I'm looking at putting the token in either the message body or the URL. Putting it in the URL has somewhat of a bad reputation, security-wise. However, I just read up on session hijacking, CSRF and XSS, and I couldn't really see why it should be worse than cookies. If anything, not having a cookie that is transparently sent along whenever you access a particular domain is more secure, or is it?
Basically, the only reason I can see is that the token is visible in the request and might be leaked via the browser history, a web server log etc. How bad is this really, and are there ways to mitigate risks? What other risks might there be?
How bad is this? Well, one of our competitors had a link from their internal (session based pages) to our site and I saw it on the server logs. Quick copy and paste with the /sess/sess_34984923_34423423/ type stuff and I was logged into their system with full access permissions of that user (luckily, they weren't an administrator and it wasn't anything "super secure" like a bank/email etc: but still).
Also, depending on how exactly you implement it, the full url (including the session token) could be cache by proxy servers and even by Google (if people use the Google toolbar).
The way I've done this Flash session interactivity is to send a session identifier in the Flash parameters (in the HTML) to the Flash which then sends it back to the server. I've found most browsers/Flash combinations also send the cookie which I further authenticate against.
I have an anecdote for you. I was filling out some paperwork for a well known company in the US. They printed out a confrontation page generated by a web application, how do I know? At the bottom of the page Window's print manager included the URL which had the JSSESSIONID.
Let me be clear, the employee just handed me a sheet of paper that would allow me to login immediately as if I had their username and password. DOAH!
I suggest you further read on a very severe security topic called Session Hijacking which allows a malicious attacker to impersonate to a user once he have his session id.