Deny Server Variables

P

Pirooz Javan

Is there any way to deny a server variable to be run on a server such
as LOCAL_ADDR?

Thanks in advance.

PJ
 
P

Pirooz Javan

No. Why would you want to even try?
Usually, the question is the other way around: "why does such-an-such
servervariable contain no data?"
Do you understand where the data in the servervariables comes from?

http://msdn2.microsoft.com/en-us/library/ms525396.aspx

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

I never undstand why people decide to give their opinion rather then
answer the question.

Like I said in my original post. I need to deny users from executing
"some" server variables to get information. Does anyone know how to
do that?

Pirooz
 
D

Dave Anderson

"Pirooz Javan" "wrote":
I never undstand why people decide to give their opinion rather then
answer the question.

Good for you. What does that have to do with Bob's response? He offered no
opinion.

Like I said in my original post. I need to deny users from executing
"some" server variables to get information. Does anyone know how to
do that?

Nobody knows how to do that, because you cannot "execute" a server variable.
 
B

Bob Barrows [MVP]

Pirooz said:
I never undstand why people decide to give their opinion rather then
answer the question.

Like I said in my original post. I need to deny users from executing
"some" server variables to get information. Does anyone know how to
do that?
I don't believe I offered an opinion. Look at my very first sentence. It
should be easy to understand: it consists of a single word. No opinion
there. A very clear-cut answer, I think.

Everything I wrote after that first sentence was an attempt to better
understand your problem, which is still not stated very clearly.

First of all, servervariables are not "executed". The Servervariables
collection is a collection of information taken from http headers of a
Request. It is information, not executable code.

Secondly, a user sitting at a browser does not read the servervariables:
it's the code, written by a developer and running on the server that
reads the variables. So I guess one answer would be to tell the
developers writing the code to be run on your server that their code
should not attempt to read those variables.

However, if you are happy with a single-word answer, I offer it again:

No.
 
P

Pirooz Javan

I don't believe I offered an opinion. Look at my very first sentence. It
should be easy to understand: it consists of a single word. No opinion
there. A very clear-cut answer, I think.

Everything I wrote after that first sentence was an attempt to better
understand your problem, which is still not stated very clearly.

First of all, servervariables are not "executed". The Servervariables
collection is a collection of information taken from http headers of a
Request. It is information, not executable code.

Secondly, a user sitting at a browser does not read the servervariables:
it's the code, written by a developer and running on the server that
reads the variables. So I guess one answer would be to tell the
developers writing the code to be run on your server that their code
should not attempt to read those variables.

However, if you are happy with a single-word answer, I offer it again:

No.

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.- Hide quoted text -

- Show quoted text -

That actually helped. Your first response said no, but then asked why
I would even try to do that (which is irrelative to an answer). To
help you understand better, I'm at a govt agency that is not permitted
to let the internal IPs of the web servers get out. Since we support
many different applications, its difficult to filter all the content
being uploaded to the web servers (500+ apps).

A nightly parser would work for ASP, but wouldn't for dlls. So there
is no other options?

PJ
 
B

Bob Barrows [MVP]

Pirooz said:
That actually helped.

Really? I said nothing that was not said in my first post, given that
you took the trouble to read the link I provided, that is ... :)
Your first response said no, but then asked why
I would even try to do that (which is irrelative to an answer).

It's "irrelative" only if you fail to take it literally. Read it as an
attempt to understand your problem.
To
help you understand better, I'm at a govt agency

Ah! I now I undestand the reluctance to say too much ... :)
that is not permitted
to let the internal IPs of the web servers get out. Since we support
many different applications, its difficult to filter all the content
being uploaded to the web servers (500+ apps).

OK, now we are getting somewhere. So you are looking for a way to ensure
that the servervariables containing information about the internal
servers (LOCAL_ADDR, etc.) always contain empty strings. Unfortunately,
I personally don't know how this could be done, but that does not mean
it isn't possible. Hopefully, one of the IIS guys will jump in here and
bail me out. If nobody here can give you an answer, you might try at the
inetserver.iis group. Just make sure you state your problem clearly as
you did in this last reply.
 
T

Tim Slattery

That actually helped. Your first response said no, but then asked why
I would even try to do that (which is irrelative to an answer). To
help you understand better, I'm at a govt agency that is not permitted
to let the internal IPs of the web servers get out.

I'm not entirely sure what you mean by that. If your user doesn't have
the IP address of your web server, he can't connect to it at all! If
the server can be connected to from inside the agency by another IP
address, that information won't be available to the outside web user
anyway.
 
B

Bob Barrows [MVP]

Tim said:
I'm not entirely sure what you mean by that. If your user doesn't have
the IP address of your web server, he can't connect to it at all! If
the server can be connected to from inside the agency by another IP
address, that information won't be available to the outside web user
anyway.

I was assuming that he had an external outward-facing site that ran apps
on internal servers. Is that correct Pirooz? You wish to prevent the
apps on the internal sites from being able to return data about those
servers to the external users?
 
M

Mark J. McGinty

Bob Barrows said:
I was assuming that he had an external outward-facing site that ran apps
on internal servers. Is that correct Pirooz? You wish to prevent the
apps on the internal sites from being able to return data about those
servers to the external users?

Allowing external third parties to upload code and execute it on your
servers is an inherently dangerous activity. Given the ability to do that,
what more advantage is there to be gained by knowing the internal IP? Seems
like closing the barn doors after the cows are gone.

Oh wait, this is government IT, so the assumption that requirements map to
valid underlying reasons is a false one. Sort of like Amtrak requiring ID
to purchase a ticket, while allowing anyone standing on the platform to get
on the train -- a do-nothing 'safety' measure that in all actuality has no
effect on safety at all.

And you allow them to upload/run DLLs too? The only approach to satisfying
your requirement I can imagine, would be an ISAPI filter that scans output
before it is sent to the requesting client, by registering for, and
processing SF_NOTIFY_SEND_RAW_DATA. There are surely other details that
need to be filtered from output; the challenge becomes maintaining a current
list of their values, and efficiently identifying any occurence of those
values in output. (Assuming that efficiency is important here, if not feel
free to ignore that qualifier.)

Of course, this will not be very effective if the third party code writers
obfuscate or hide the forbidden details, even just separating the quads with
something other than dots would defeat it rather handily... which brings us
back to my earlier point about uploaded code: if someone you allow to
upload/exec code on your servers wants to embed 'secret' details in the
output, you might slow them down, but you won't stop them.

Also worthy of note is that IIS headers are not the only source of the
system's local IP, so even if you could control that ServerVariable, it
would gain little in the way of protecting that detail, if it gained
anything at all.

-Mark
 
E

Evertjan.

Mark J. McGinty wrote on 23 sep 2007 in
microsoft.public.inetserver.asp.general:
Oh wait, this is government IT, so the assumption that requirements
map to valid underlying reasons is a false one. Sort of like Amtrak
requiring ID to purchase a ticket, while allowing anyone standing on
the platform to get on the train -- a do-nothing 'safety' measure that
in all actuality has no effect on safety at all.

Could you repeat that without your regional settings?

ID surely being a clientside thing, not part of the ASP platform?

;-}
 
M

Mark J. McGinty

Evertjan. said:
Mark J. McGinty wrote on 23 sep 2007 in
microsoft.public.inetserver.asp.general:


Could you repeat that without your regional settings?

Sorry, I don't have an internationally relevant parallel... my hope is that
this particular level of stupidity is specific to the USA. :) This same
organization has machines in some stations that will let you buy a ticket
with a gift card Visa, but god forbid you even think about trying to buy one
from an agent behind the counter, without a *valid* government picture ID.
If it's one day expired, they will turn you away.
ID surely being a clientside thing, not part of the ASP platform?

Eh... credentials... could go either way. :)


-Mark
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,085
Messages
2,570,597
Members
47,219
Latest member
Geraldine7

Latest Threads

Top