David
Fri Dec 10 09:01:49 CST 2004
> This make sound silly, but we have nod been seeing this
> and we had assumed that the 302 was handled quietly and
> that the URL did not change until the resource was acquired.
Ah, a bank. Think think about it this way - a browser is literally
obligated to show the new URL of a 302. If a web server just told the
browser "go there instead", it would be totally negligent for the browser to
hide this fact from the user. This is the sort of problem that cross-site
scripting vulnerability thrives on.
It is a good piece of info to know that there is a reverse proxy. You need
to figure out whether this reverse proxy remaps both IP and Ports. In other
words, outside clients request a.b.c.d:80 and the reverse proxy
translates it to e.f.g.h:8080 in the internal network.
Clearly, the ASP page needs to tell the client to make a 302 redirection to
a.b.c.d:80 , but while the ASP page is running, it may not know a.b.c.d
nor 80 (it knows it is running on a website at e.f.g.h on port 8080, but it
knows nothing about the reverse proxy).
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Neil Kiser" <neil@NOSPAMkiserville.com> wrote in message
news:36E7EBEB-0696-4D80-9E81-5D7E46EB56FE@microsoft.com...
I completely concur with you, and unfortunately can not comply. There's no
excuse for it, but the explanation is that I work for a major bank and as
such, our divisions are segmented. I have no ability to affect the
environment in which this testing must be done and there are many clients
for
many other apps that reach this environment. In short, while you are 100%
correct, I couldn't get SSL turned off to save my life. However, you have
answered my question indirectly. I will assume then that there are no known
issues with reverse proxy servers and response.redirect/302 messages.
I am confident that my code is good. The application works fine if I call
it directly, it is only when the URL is masked by a reverse proxy that the
problem arises. I appreciate that you can not help me without more
information, and it is logical to request that SSL be turned off. But, I'll
have to proceed without that benefit. We did advanced yesterday in that I
realized that if the browser receives a 302 instruction that it updates the
address/URL and then makes the request. This make sound silly, but we have
nod been seeing this and we had assumed that the 302 was handled quietly and
that the URL did not change until the resource was acquired. Now that we
know this, we are uncertain that the 302 is actually making it back to the
browser. Our current thinking is that perhaps the proxy server is set to
optimize communications and to handle the 302 without involving the client
browser. Not being proxy server informed, I have no idea if this is true.
So we muddle forward. Thank you for your help.
-Neil K.
"David Wang [Msft]" wrote:
> Your redirection is ambiguously defined that it is more likely than not to
> result in a 404. Please do the whole thing with just HTTP to prove that
> everything is correct before moving to HTTPS.
>
> If you cannot, then you are on your own to first prove your code is
> redirecting the way it is supposed to before claiming there is an issue
with
> any proxy/IIS -- just because SSL obscures the issue by encrypting traffic
> does not shield you from due diligence.
>
> You can use a Netwo