0

I have Web Application A on Server A that links to Web Application B on Server B. I'm linking to a form that I want to pre-populate with data from Web Application A. So:

Web App A --Links to form and sends data for pre-population--> Web App B

Since they're on seperate servers I importunately can't just plop something into Session, so I'm going to have to be a little more creative. I'm considering a few different options and I'm looking for the simplest of those solutions. Any suggestions?

Here's a few options I'm considering:

  • Pass the form data in the link via query string parameters. This seems simple enough, is the legit to do? Or is it a security concern? I'd be passing about 8 parameters, the most sensitive being e-mail address and address. This would all be over SSL.
  • Similarly, I could pass the data as POST parameters.
  • Web App A writes a cookie, Web App B reads the data from the cookie. (This seems like more of a security concern than passing as GET or POST parameters)
  • I could share an object via JNDI to use for prepopulation. Then I guess I could pass a unique ID on the query string which Web App B could use to pick up the object. This seems like it might be "overkill" and I'm not sure how this would work.
  • I could store the data in a database against a unique ID, pass the unique ID on the query string, then pick it up in Web App B from that same database. Again, this might be "overkill".

Any thoughts? Or is there a better solution that I don't have listed?

Community
  • 1
  • 1
JasonStoltz
  • 3,040
  • 4
  • 27
  • 37

2 Answers2

1

In my opinion the GET params are the simplest way to do it, and I don't think there are important security implications.

Henry
  • 6,502
  • 2
  • 24
  • 30
  • True, i was thinking a form with hidden fields submitted via javascript for POST. – JasonStoltz May 12 '11 at 13:25
  • You could do the POST request, but can you cause the browser to go there with the request? In other words, not do an ajax request, but cause a *normal* POST request? Also the POST is not modifying anything so it's 'bad form'. – Henry May 12 '11 at 13:28
  • Pretty sure. As long as I have a form element on the page, I can just do a "form.submit()" which should instruct the browser to execute a POST request. It has the same effect as if the user would submit the a form request regularly. – JasonStoltz May 12 '11 at 13:30
  • To your second point, that's true, probably not good form. The thing I like about that is that it is invisible to the user, meaning there no big query string. – JasonStoltz May 12 '11 at 13:31
  • Ah right, of course a simple form.submit() would work :) Also a refresh would cause a warning 'are you sure you want to resubmit'. I really prefer GET but you're right POST would work fine. – Henry May 12 '11 at 13:35
  • Maybe with the get parameters... it could be something like 1) pass the parameters on the GET request 2) Web app receives parameters, and stores the data in session 3) web app redirects back to itself without the long query string and pre-populates from the form data in session. This way, the query string is ultimately hidden from the user, and I don't have the baggage associated with the POST request. Any thoughts on that? – JasonStoltz May 12 '11 at 13:37
1

You should assume anything that web app A puts in the redirect can be read/stolen/modified/spoofed before it gets to web app B (unless you are using SSL on both app A and B). If this isn't a problem then putting the params on the redirect URL should do you fine.

A secure way would be for app A to generate a unique ID (non guessable and short lived) and to store the info against this ID. The ID is passed with the request to app B. Server B then accesses the data from server A using the ID in a private secure way, for example be calling a web service on server A that is not publically accessible.

Qwerky
  • 18,217
  • 6
  • 44
  • 80
  • Thanks for the answer. They actually are both using SSL, so I guess as you said, that shouldn't be a problem. Also, if I did decide to go with the unique ID suggstion, I think it would be even easier because they both read/write to a common database. That would eliminate the need for a web service on server A. – JasonStoltz May 12 '11 at 17:58
  • @Jason Just make sure the ID passed is short lived (less than 20s) and non guessable (at least 128 bit) otherwise you may end up in this situation; http://www.theregister.co.uk/2007/12/04/canadian_passport_site_breach/ – Qwerky May 13 '11 at 07:36
  • Thank you so much for the answer! This is exactly what I was looking for; the security "gotchas" of these approaches. – JasonStoltz May 13 '11 at 11:53