SSL VPN
Reply
Contributor
minifig
Posts: 10
Registered: ‎04-19-2012
0
Accepted Solution

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

Trusted Contributor
mattspierce
Posts: 107
Registered: ‎07-27-2010
0

Re: Discussion on change url possibilities

[ Edited ]

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.

Contributor
minifig
Posts: 10
Registered: ‎04-19-2012
0

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?

 

Moderator
zanyterp
Posts: 2,332
Registered: ‎11-19-2007
0

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.

Contributor
jspanitz
Posts: 216
Registered: ‎08-02-2011
0

Re: Discussion on change url possibilities

[ Edited ]

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]

Moderator
zanyterp
Posts: 2,332
Registered: ‎11-19-2007
0

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.

Contributor
minifig
Posts: 10
Registered: ‎04-19-2012
0

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.

Contributor
minifig
Posts: 10
Registered: ‎04-19-2012
0

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.

df
Contributor
df
Posts: 58
Registered: ‎11-24-2008
0

Re: Discussion on change url possibilities

[ Edited ]

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.

Contributor
minifig
Posts: 10
Registered: ‎04-19-2012
0

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.

 

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.