What the programing language can send http post or get from client in web brower ?
i think flash actionscript or ajax or java applet not working for cross domain security thanks
Nothing in the browser sandbox will get past cross-domain security (which is exactly the point of having a sandbox in the first place).
You'd have to write a native browser plugin or use a Java applet that asks for "unlimited system access".
Another option would be to use the one domain that you can access via XHR to act as a proxy (have some code there that fetches the result from the domain you really want to access). You can even forward cookies and such, but for the target domain it looks like the request is coming from your data center (not the end user's browser).
You can send requests with javascript using XHR (you may have heard this referred to as AJAX before) if you control the destination server, you can host a page on the second domain that does the ajax request and stores the result in a window level variable, and put that in an iframe for the first domain. After that, any time you want to make the request, you use javascript to refresh the iframe and grab the variable out of it.
Total hack, but AFAIK its the only way to do it.
Related
So I have few things to say I don't want to use cookies so things like express-session doesn't come as option.
I use nodejs with express with no front-end JavaScript and mysql as database. I don't really know how to do it so I would like to hear your opinion.
I already tried to search on internet.
When dealing with regular web pages, there are only four places in a request to store information that would identify a session.
Cookie sent with each request
Custom header on each request
Query parameter with each request
In the path of the URL
You've ruled out the cookie.
The custom header could work for programmatic requests and is regularly used by Javascript code with various types of tokens. But, if you need a web browser to maintain or send the session on its own, then custom headers are out too.
That leaves query parameters or in the path of the URL. These both have the same issues. You would create a sessionID and then attach something like ?sessionID=92347987 to every single request that your web page makes to your server. There are some server-side frameworks that do sessions this way (most have been retired in favor of cookies). This has all sorts of issues (which is why it isn't used very often any more). Here are some of the downsides:
You have to dynamically generate every single link in a web page so that it will include the right sessionID as part of the link so if the user clicks on it, the resulting http request will have the right sessionID included.
All browser caching has to be disabled or bypassed because you don't want the browser to use cached web pages that might contain the wrong sessionID.
User bookmarks basically don't work because they end up bookmarking a URL with a sessionID in it that won't last forever.
The user sees sessionID=xxxx in all their URLs.
Network infrastructure that log the URLs of requests will include the sessionID (because it's in the URL). This is considered a security risk.
All that said and with those tradeoffs, it can be made to work, but it is not considered the "safest" way to do it.
I'm trying to create a bookmarklet which needs to hit a server (using a POST) to obtain some data. Accessing that data requires that I am logged in, which is kept track of by using cookies. The problem is, my bookmarklet is running in the context of some random web site, and so it can't access the cookies belonging to the site I am trying to hit and in fact it doesn't even send the cookies that belong to that web site.
I have seen some hints that suggest that what I am trying to do is possible, but which are a bit unclear on exactly how this could be accomplished. For instance, in this question, the accepted answer includes this tidbit: "Very often these types of bookmarklets open a small popup for the user which contains a page from the app" but I do not understand how this would accomplish what I am trying to do. I assume it has something to do with the fact that the page itself is in the proper domain and thus can send the required cookies, but I'm not sure how to get data into the page to tell it what I want (I suppose I could do something where I encoded the request in the URL parameters, but then this would show up in the http logs which is not desirable), but more importantly I am not sure how I would get the data back from the window - whenever I try I get an exception "Permission denied to access property 'document'" (or whatever I try to access). I also get the same problem if I use an IFRAME and try to access the parent from the child (or the other way around).
You have asked several quetions.
1.) How can I send cookies from a bookmarklet XMLHttpRequest which belong to the site being accessed?
XMLHttpRequest will send cookies belonging to the domain you are calling. If you want to cross domains you have to enable CORS: http://enable-cors.org/
2.) "Very often these types of bookmarklets open a small popup for the user which contains a page from the app"
This is not about making an XMLHttpRequest. The data goes into the popup via GET. You can even do this via POST but it is slightly more complex. Just search "post to popup" or "post to iframe".
3.) I am not sure how I would get the data back from the window
If the other window/iframe is holding a page from a different domain, use postMessage: https://developer.mozilla.org/en-US/docs/Web/API/window.postMessage - this can actually go in both directions and can actually be used to enable complex cross domain communication without CORS.
Of late I have been diving deep into web application security. While browsing I found WebScarab Tool from OWASP which can inject possible attack in to your web application and make your application vulnerable.
I am using that tool to intercept any request which goes through my web application based on JSF 1.2 Framework. While using I observed that whatever values are entered in form fields are shown as it is HttpRequest in this tool.You can modify these values and it will automatically create a new request header and strikingly the modified values will be inserted into the DB.
Isn't it a potential attack? I mean anyone can intercept any HttpRequest and modify the parameter with the help of a tool and inject some malicious content,
My questions are:
Is it possible for everyone to intercept HttpRequest generating from any webpage, say stackoverflow.com?
If yes, how can you avoid these modification by an unknown user who can modify the parameter and remake the encoded URL?
If no, please explain why? I am absolutely numb?
WebScarab is a proxy:
WebScarab operates as an intercepting proxy, allowing the operator to review and modify requests created by the browser before they are sent to the server, and to review and modify responses returned from the server before they are received by the browser.
But this requires the client (e.g. your web browser) to actually use the proxy:
In order to start using WebScarab as a proxy, you need to configure your browser to use WebScarab as a proxy. This is configured in IE using the Tools menu. Select Tools -> Internet Options -> Connections -> LAN Settings to get the proxy configuration dialog.
So only the communication of clients that use the WebScarab proxy can be intercepted.
Using WebScarab or other UI Interceptor tool, person can Change the Transaction data in between of processing of request from Client to Server.
Basically this can be avoided by applying Same Validations at both Client and Server side of the application.
eg, if Application has Change pwd functionality, and someone tries Interceptor and modifies the pwd with new intercepted Pwd., while saving it should be validated on server side , whether user entered correct password or not.
Like a lot of developers, I want to make JavaScript served up by Server "A" talk to a web service on Server "B" but am stymied by the current incarnation of same origin policy. The most secure means of overcoming this (that I can find) is a server script that sits on Server "A" and acts as a proxy between it and "B". But if I want to deploy this JavaScript in a variety of customer environments (RoR, PHP, Python, .NET, etc. etc.) and can't write proxy scripts for all of them, what do I do?
Use JSONP, some people say. Well, Doug Crockford pointed out on his website and in interviews that the script tag hack (used by JSONP) is an unsafe way to get around the same origin policy. There's no way for the script being served by "A" to verify that "B" is who they say they are and that the data it returns isn't malicious or will capture sensitive user data on that page (e.g. credit card numbers) and transmit it to dastardly people. That seems like a reasonable concern, but what if I just use the script tag hack by itself and communicate strictly in JSON? Is that safe? If not, why not? Would it be any more safe with HTTPS? Example scenarios would be appreciated.
Addendum: Support for IE6 is required. Third-party browser extensions are not an option. Let's stick with addressing the merits and risks of the script tag hack, please.
Currently browser venders are split on how cross domain javascript should work. A secure and easy to use optoin is Flash's Crossdomain.xml file. Most languages have a Cross Domain Proxies written for them, and they are open source.
A more nefarious solution would be to use xss how the Sammy Worm used to spread. XSS can be used to "read" a remote domain using xmlhttprequest. XSS isn't required if the other domains have added a <script src="https://YOUR_DOMAIN"></script>. A script tag like this allows you to evaluate your own JavaScript in the context of another domain, which is identical to XSS.
It is also important to note that even with the restrictions on the same origin policy you can get the browser to transmit requests to any domain, you just can't read the response. This is the basis of CSRF. You could write invisible image tags to the page dynamically to get the browser to fire off an unlimited number of GET requests. This use of image tags is how an attacker obtains documnet.cookie using XSS on another domain. CSRF POST exploits work by building a form and then calling .submit() on the form object.
To understand the Same Orgin Policy, CSRF and XSS better you must read the Google Browser Security Handbook.
Take a look at easyXDM, it's a clean javascript library that allows you to communicate across the domain boundary without any server side interaction. It even supports RPC out of the box.
It supports all 'modern' browser, as well as IE6 with transit times < 15ms.
A common usecase is to use it to expose an ajax endpoint, allowing you to do cross-domain ajax with little effort (check out the small sample on the front page).
What if I just use the script tag hack by itself and communicate strictly in JSON? Is that safe? If not, why not?
Lets say you have two servers - frontend.com and backend.com. frontend.com includes a <script> tag like this - <script src="http://backend.com/code.js"></script>.
when the browser evaluates code.js is considered a part of frontend.com and NOT a part of backend.com. So, if code.js contained XHR code to communicate with backend.com, it would fail.
Would it be any more safe with HTTPS? Example scenarios would be appreciated.
If you just converted your <script src="https://backend.com/code.js> to https, it would NOT be any secure. If the rest of your page is http, then an attacker could easily man-in-the-middle the page and change that https to http - or worse, include his own javascript file.
If you convert the entire page and all its components to https, it would be more secure. But if you are paranoid enough to do that, you should also be paranoid NOT to depend on an external server for you data. If an attacker compromises backend.com, he has effectively got enough leverage on frontend.com, frontend2.com and all of your websites.
In short, https is helpful, but it won't help you one bit if your backend server gets compromised.
So, what are my options?
Add a proxy server on each of your client applications. You don't need to write any code, your webserver can automatically do that for you. If you are using Apache, look up mod_rewrite
If your users are using the latest browsers, you could consider using Cross Origin Resource Sharing.
As The Rook pointed out, you could also use Flash + Crossdomain. Or you could use Silverlight and its equivalent of Crossdomain. Both technologies allow you to communicate with javascript - so you just need to write a utility function and then normal js code would work. I believe YUI already provides a flash wrapper for this - check YUI3 IO
What do you recommend?
My recommendation is to create a proxy server, and use https throughout your website.
Apologies to all who attempted to answer my question. It proceeded under a false assumption about how the script tag hack works. The assumption was that one could simply append a script tag to the DOM and that the contents of that appended script tag would not be restricted by the same origin policy.
If I'd bothered to test my assumption before posting the question, I would've known that it's the source attribute of the appended tag that's unrestricted. JSONP takes this a step further by establishing a protocol that wraps traditional JSON web service responses in a callback function.
Regardless of how the script tag hack is used, however, there is no way to screen the response for malicious code since browsers execute whatever JavaScript is returned. And neither IE, Firefox nor Webkit browsers check SSL certificates in this scenario. Doug Crockford is, so far as I can tell, correct. There is no safe way to do cross domain scripting as of JavaScript 1.8.5.
HTTP Referer is the way I'm doing it at the moment. As everyone who's used this method knows it is not 100% accurate as the Referer header is optional and maybe fiddled with.
Looking at how-to-ensure-access-to-my-web-service-from-my-code-only I'm still unsure of how to go about this in a minimal way.
The situation:
Advertising on someone else's site. Using an iFrame so I can change content/function at will. I pay $x.xx for every time an action is completed. Therefore I need to ensure that the action is being completed from where I said it is allowed to be completed from.
What I'm trying to prevent:
some other webmaster coming along going - "hey that's a nice tool, let me put that on my site"
So as i said at the top, what i do atm is if the referer doesn't match I redirect to a page that has the same tool however whatever actions are preformed on that page they don't cost me any money.
While trying to prevent the above, allow the following:
I don't mind if the webmaster/site owner I'm paying cash to for "actions complete" puts the code on other sites - obviously this is a good thing. Lots more coverage, the site owner gets more cash & i get more actions completed, which generates me more cash.
Question
What can I get the other party to do so I know all the requests coming into my web page are from the other party I have an agreement with and not some random.
Thanks :)
info re app
other parties website has an iFrame. iFrame displays a html/js/php page of mine that sits on one of my domains. This page uses ajax requests to interact with the actual webservice that is a ruby/sinatra app. I have lots of different pages that fit into the look and feel of the other parties website.
So I'm thinking some sort of chatter between the other parties server and my server would be a good idea. Then the result of this chatter would be somehow present during the iFrame request.
However I'm not sure if the other party would be able to set a cookie for the domain being served in the iFrame - in fact I'm pretty sure it can't.
Now to get around that limitation I could have a script included as part of the iFrame on the page that could set a cookie.
Ok the above ideas summarised:
OtherParty server sends a request to my server gets a response.
renders the page with that response as a param to a <script src="...?param"></script>
my script sets a cookie
as script is before iFrame, script is loaded first
iFrame loads with page as a cookie has been set on that domain cookie set before is sent as well
bingo, request verified legit
Does this sound ok?
btw my tool that I want action completed on only works if JS is enabled so...
If you really want to secure who can load your iframe, then one way to do this is via 2-legged OAuth (i.e. have your trusted partner "sign" the iframe GET request). Then your server can grant access based on a cryptographically valid signature and a known signing party. You'll want to enforce relatively short valid lifetimes for the signed requests to prevent someone else from just copying them and embedding them in their own site.
This also gives you the advantage of just having to do an initial, offline key exchange without having your partner making extra server requests of you ahead of the iframe insertion.