1

Is there any web language that allows the client itself to create HTTP posts to external sites.

I know that JavaScript does this with XMLHttpRequest, but it does not allow cross-domain posting, unless the recipient domain wants to allow the sending domain.

I want to post data to an external site (that I don't control) and have the request be authenticated with what the client's browser already has (cookies, etc).

Is this possible? I tried cURL but it seems to make a server HTTP post, not a client HTTP post.

Edit:

A bit more insight of what I am trying to do:

I am trying to POST JSON to the website using the user's session (I said cookies but I believe they are PHP sessions, which I guess I still consider cookies).

The website does NOT check the referral (poor security #1) I can execute javascript and html on the webpage using my personal homepage (poor security #2) The JSON code will still work even if the content-type is form (poor security #3) There is no security checking at all, just PHP session checking.

The form idea is wonderful and it works. The probably again is that its JSON. So having sent postdata as foo={"test":"123", "test2":"456"} the whole foo= part messes it up. Plus forms seem to turn JSON into form encoding, so its sending:

foo=%7B%22 test%22%3A+%22 123%22%2C+%22 test2%22%3A+%22 456%22%7D

when i need it to send;

{"test":"123", "test2":"456"}

So with everything known, is there a better chance of sending JSON or not?

ParoX
  • 5,685
  • 23
  • 81
  • 152
  • #1 I wouldn't consider not checking a referral poor security, it's the same thing as asking "So where did you come from? Oh good, come on in. Promise your name's not Mallory? Great!" There's not legitimate security behind this and anybody who's used wget or even firefox's live http headers can easily spoof it in seven seconds. #3 can also be changed to content type = "Magic spaghetti pasta," and I could ship them ajax json full of arrays with juicy bacon in them. So I wouldn't see that as a real threat to security either. #2 is a problem however. – Incognito Aug 03 '10 at 21:01

5 Answers5

2

I don't think so: You won't get hold of the user's auth cookies on the third party site from server side (because of the Single Origin Policy) and you can't make Ajax requests to the third party site.

The best you can do is probably create a <form> (maybe in an <iframe>), point it to the third party site, populate it with data, and have the user submit it (or auto-submit it). You will not be able to get hold of the request results programmatically (again because of the Single Origin Policy), but maybe it'll do - you can still show the request results to the user.

Pekka
  • 442,112
  • 142
  • 972
  • 1,088
  • @Pekka you bring up an interesting thought right now that I have never stopped to think about before. So I can't behind the scenes submit a form and get back results on behalf of the user, say uysing ajax. But...if I had a hidden iframe in my site that read cookies from the machine, posted a form to a remote site, scraped the screen with javascript for some juicy information, then posted another hidden form to my site that was recording that information that would be ok. Am I missing something in security that I am just overlooking? It can't be that easy can it? – spinon Aug 03 '10 at 19:39
  • @spinon You can't do it for any properly programmed web site (what you want to do is a cross site request forgery). – Artefacto Aug 03 '10 at 19:41
  • @spinon no, that's not possible because you can't access any part of the document using Javascript. You can't even fetch single pixels from it: http://stackoverflow.com/questions/1936021/javascript-eyedropper-tell-colour-of-pixel-under-mouse-cursor – Pekka Aug 03 '10 at 19:42
  • @Artefacto My interest has been peaked. What do you mean by properly programmed website? I still am not seeing what would prevent me from doing something like this? I am sure there must be something I am missing? – spinon Aug 03 '10 at 19:43
  • @Pekka oh ok that is right. Now I remember that. I knew I was missing something. Thanks for cleaning up my brain fart. Duh!! – spinon Aug 03 '10 at 19:44
  • @spinon A form submission made from another site should not be possible in a site that generates a token per form display (or even per session) and then validates that token on form submission. Google for CSRF. I don't know much about Javascript, but additionally, according to what Pekka claims, even if the form submission succeed, you wouldn't be able to read the result back. – Artefacto Aug 03 '10 at 19:46
  • @Artefacto you are right: Using a form this way *is* a form of CSRF - albeit a legitimate one. – Pekka Aug 03 '10 at 19:48
  • @Pekka yeah I know about that approach but in practice I don't think a lot of smaller sites are using it. – spinon Aug 03 '10 at 20:15
0

I think for obvious reasons this is not allowed. If this was allowed what would stop a malicious person from posting form data from a person's browser to any number of sites in some hidden iframe or popup window.

If this is a design of your application you need to rethink what you are trying to accomplish.

EDIT: As @Pekka was pointing out I know you can submit a form to a remote site using typical form submits. I was referring to using some client side ajax solution. Sorry for the confusion.

spinon
  • 10,760
  • 5
  • 41
  • 59
  • It's no problem to post form data from a person's browser to an external site. It's just impossible to make a full Ajax request to one, and get the response back programmatically. – Pekka Aug 03 '10 at 19:38
  • @Pekka yeah that is what I was trying to say just not as clearly. Read the comment I left on yours though about something I never thought about before. – spinon Aug 03 '10 at 19:40
0

You should follow the way OpenID and other single-sign-on system works. How openID works is your website POSTs some token to openID service and in return gets authentication result. Refer How Does it Work? section here

ankitjaininfo
  • 11,961
  • 7
  • 52
  • 75
  • Will probably not work because he doesn't control the external site he needs to make the request to. – Pekka Aug 03 '10 at 19:40
0

Yes, you can use a special flash library that supports cross-domain calls: YUI connection manager

Added: not sure about the cookie authentication issue though...

Larry K
  • 47,808
  • 15
  • 87
  • 140
  • This sounds good, but I think Flash doesn't use the browser's cookies when making the request. It might be possible to add them manually, though. – Pekka Aug 03 '10 at 19:46
  • The key thing here are the cookies. If they weren't required he could as well setup a reverse proxy in his domain. – Artefacto Aug 03 '10 at 20:02
-1

The client cannot post to an external site directly; it's a breach of basic cross-domain security models. The exception is accessing javascript with JSONP. What you describe would require access to a user's cookies for another website, which is impossible as the browser only allows cookie access within the same domain/path.

You would need to use a server-side proxy to make cross-domain requests, but you still cannot access external cookies: http://jquery-howto.blogspot.com/2009/04/cross-domain-ajax-querying-with-jquery.html

Ian Wetherbee
  • 6,009
  • 1
  • 29
  • 30
  • 1
    The server-side proxy won't really help either, because there are authentication cookies in the client's browser he seems to need to use for the operation. – Pekka Aug 03 '10 at 19:40
  • I said access to cookies is impossible, which includes client+server side methods. – Ian Wetherbee Aug 03 '10 at 20:05