cancel
Showing results for 
Search instead for 
Did you mean: 

Discussion on change url possibilities

SOLVED
Highlighted
Occasional Contributor

Discussion on change url possibilities

I'll try to make this as short as possible:
- we have a SA2500 with 7.1R6 (build 20169)
- we defined some bookmarks for the external users
- users can not type URLs in the IVE browse bar
- hostnames are masked while browsing

So when a user uses one of the bookmarks, the link in the browser looks something like this:
https://server/dana/home/launch.cgi?url=.ahuvs%3A%2F%2Fpv21lsr7

So far so good. The problem is that the user can change this url to e.g. https://server/dana/home/launch.cgi?url=cvs which brings him to our cvs server! :-o
Something that should not be possible.

Our supplier told me that I should use allow and deny rules to fix this, but that's not the point I want to make. I don't understand that our SA2500 allows a user to change the url into something that actually works. The SA2500 should tell the user something like "Don't fiddle with links".

I found a similar answer in this forum here (if it works) :http://forums.juniper.net/t5/SSL-VPN/Modification-of-url-next-to-be-logged-in/m-p/123927/highlight/t...

But I don't agree to the fact that a user can change this link.

Can someone tell me why this is possible?

Greetings,

Roger

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Respected Contributor

Re: Discussion on change url possibilities


@minifig wrote:

@zanyterp wrote:

I have not seen explorer be able to prevent a user from using the address bar to attempt changing where they are connected against and apologize for that; the only behavior I have seen is the same as the SA: the user can type whatever they want in the address bar; the ACLon the server then determines if access should be allowed or not.

 

back to the windows analogy, you can access locations that are not shared by using the hidden link on the <x> drive (e.g. C$, D$, Z$). if the user knows the full internal path, thety can type it in the address bar in explorer and connect. the server ACLs will then allow or deny access.



I did not state that explorer on the client can control what you type in the address bar.  I stated that the server that you want to access does.

 

For the Windows analogy: you can only access those (default) administrative shares if you are an administrator. These are not accessible for a common user.

 

But I'll leave it at that now. It seems I'm the only one who thinks that fiddling with an obfuscated link should be allowed by an SA.

Contacting my account team to solve this and make an option out of it that seems to be considered as usefull by members here is not going to happen.


i apologize for misunderstanding. the SA controls what you access as well. i think what you are proposing, restricting access if a user modifies the obfuscated URL is a great idea. i can only speak for myself, but i didn't read any of the posts as sating that users can change the URL is good, only that the system currently allows it and the ACL has the final say in access. 

View solution in original post

20 REPLIES 20
Highlighted
Frequent Contributor

Re: Discussion on change url possibilities

I think what you are asking would be very difficult to implement. A webserver, which is what the SA's are, don't keep state with the client. The client keeps a cookie once logged on and reminds the server of his state with each link. For what your asking to work I believe the server would have to keep track of the URL and every link in the current document a user has pulled down. That is a lot of data to keep track on the fly. The solution in the SA appliances are the Web ACL's. That is the mechansim that lets the role a user maps to get access to resources. By default I believe there are *.* access rules for the initial role. I would suggest considering removing the *.* acls. Then create resource profiles for your web pages. The profile will create an autopolicy with the ACL you need.

Highlighted
Occasional Contributor

Re: Discussion on change url possibilities


@mattspierce wrote:

I think what you are asking would be very difficult to implement. A webserver, which is what the SA's are, don't keep state with the client. The client keeps a cookie once logged on and reminds the server of his state with each link. For what your asking to work I believe the server would have to keep track of the URL and every link in the current document a user has pulled down. That is a lot of data to keep track on the fly. The solution in the SA appliances are the Web ACL's. That is the mechansim that lets the role a user maps to get access to resources. By default I believe there are *.* access rules for the initial role. I would suggest considering removing the *.* acls. Then create resource profiles for your web pages. The profile will create an autopolicy with the ACL you need.


Keeping track of what happens on the client is not really needed I think.

In our case, the links themselves are scrambled (masked hostnames) so that the user does not know what server is behind the link.

I suppose nobody can create such a link by themselves, but apparently they don't have to.

So:

1) What's the use of being able to create a link for yourself in a non-scrambled way?

2) Why can a user go to a website they choose themselves when they don't have the IVE browse bar?

Highlighted
Respected Contributor

Re: Discussion on change url possibilities

As mattspierce updated, yes, this is not something that the IVE can control.

Since you are creating all the bookmarks for users, you can choose to have them open in a new window and then remove the address bar (please note this is not supported by all browsers, specifically starting with IE7 or 8 this was removed from the IE browsers).

 

The IVE has no ability to control what happens in the browser address bar. This is a great idea to control; but I don't know if it is technically feasible.

You mitigate where users can access based on the web ACL that allows or denies access to specific sites.

Highlighted
Frequent Contributor

Re: Discussion on change url possibilities

I'd have to agree with mattspierce on this one in terms of how the SA / MAG functions.

The feature you are referring to - url obfuscation - is just that - a way to mask the backend url to hide the info from the user. If the user knows a valid URL they already have the knowledge you were trying to hide. So why bother hiding it.

What you were trying to accomplish by URL obfuscation actually needs to be done with Web ACLs as mattspierce stated. ACLs are the only way to keep users from going places they should not. Combining it with hiding the URLs denies an user without knowledge from gaining said knowledge.

That being said, if your SA is deployed with a *.* Web ACL, I would strongly recommend you fix that as any user can get to any web resource on your network (Assuming there isn't a firewall behind the internal port of the SA).

John

[Edit: Posted the same time as zanyterp - sorry for the duplicate info]

Highlighted
Respected Contributor

Re: Discussion on change url possibilities

1) The use case defined here is not about creating links, which you as an admin can deny, but about the user modifying the URL in the address bar (which cannot be restricted). The benefit of user-created links is that users may have sites they want to use frequently that the admin has not created for them.

 

2) This is not the IVE browse bar but the browser used to login, that address bar. There is no control over that address bar and users can make changes there at-will.

Highlighted
Occasional Contributor

Re: Discussion on change url possibilities


@zanyterp wrote:

1) The use case defined here is not about creating links, which you as an admin can deny, but about the user modifying the URL in the address bar (which cannot be restricted). The benefit of user-created links is that users may have sites they want to use frequently that the admin has not created for them.

2) This is not the IVE browse bar but the browser used to login, that address bar. There is no control over that address bar and users can make changes there at-will.


1) I agree that changing the URL in the address bar cannot be restricted. I don't agree that users can change this link into something that actually gives them a website. When I want a user to be able to use links of their own, I would give them the IVE browse bar of the possibility to add bookmarks themselves.

2) Exactly. But as I don't give the users the IVE browse bar, I would think they can't go to links that I didn't provide for them. Apparently they can.

Highlighted
Occasional Contributor

Re: Discussion on change url possibilities


@jspanitz wrote:

I'd have to agree with mattspierce on this one in terms of how the SA / MAG functions.

The feature you are referring to - url obfuscation - is just that - a way to mask the backend url to hide the info from the user. If the user knows a valid URL they already have the knowledge you were trying to hide. So why bother hiding it.

What you were trying to accomplish by URL obfuscation actually needs to be done with Web ACLs as mattspierce stated. ACLs are the only way to keep users from going places they should not. Combining it with hiding the URLs denies an user without knowledge from gaining said knowledge.

That being said, if your SA is deployed with a *.* Web ACL, I would strongly recommend you fix that as any user can get to any web resource on your network (Assuming there isn't a firewall behind the internal port of the SA).

John

[Edit: Posted the same time as zanyterp - sorry for the duplicate info]



Well, I obfuscate the urls so they don't know what servers are behind this service. But they don't need knowledge of the actual URL to try something like 'intranet', 'mail' or even 'cvs'.

I added the ACLs a few days ago. But the way I see it is that the ACL's are a workaround for a security issue in the SA.

I would expect for a machine like this to not accept any fiddling with the URL when using obfuscating and not having the IVE browse bar or user added bookmarks.

Highlighted
Contributor

Re: Discussion on change url possibilities

I'm confused on your statement. ACLs are "Access Control Lists". That is exactly what they do. They control access. If you allow people access to *:*, then they will have access to everything.

Its no different then giving a link to a file share in Windows Explorer. I can change the folder names in there, and if you don't control it with ACLs, then they will have access to everything.

Its not a "security workaround", its how security works.

Highlighted
Occasional Contributor

Re: Discussion on change url possibilities


@df wrote:

Its no different then giving a link to a file share in Windows Explorer. I can change the folder names in there, and if you don't control it with ACLs, then they will have access to everything.


Actually, it is different: a link to a file share is not obfuscated and is perfectly readable; the links my users get trough the SA are not. Changing these links into something readable should not work.