Pulse Secure formerly SSL VPN
Showing results for 
Search instead for 
Do you mean 
Reply
Contributor
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
Posts: 108
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
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
Posts: 2,347
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
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
Posts: 2,347
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
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
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
Posts: 59
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
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.

 

Trusted Contributor
Posts: 446
Registered: ‎05-05-2008
0

Re: Discussion on change url possibilities

In your example, you used =cvs.   If the user shouldn't have access to this resource, you should block it.   If they do have access to it, why should it matter if they bookmark it using the non-obsfucated path?   If it's because you reserve the right to change the url ever two weeks and are tired of having to update your users' bookmarks, then you have a user problem.

 

 

I had a similar issue.  I sent my users a link to the signin page and some of them opened the url...and then bookmarked it, meaning that their computer now had /dana-na/url_4......  and when I made changes, the url changed to url_5  and their bookmarks were no longer valid, even though the url in my original email remained valid.

Theodore E Van Iderstine
Stream Networks
+1 678 373 4200 x125
JNCIA-ER (expired), JNCIA-SSL (ditto)
Moderator
Posts: 2,347
Registered: ‎11-19-2007
0

Re: Discussion on change url possibilities

The users are not changing the links; they are changing a value in their address bar.

While I understand what you are saying, there is currently no way to do this. The appliance is for secure access to the network & resources you define. It is not possible to control the browser; the SA system is not a new browser but a secure access gateway. I think the idea is great, but not something it does at this time.
Highlighted
Contributor
Posts: 10
Registered: ‎04-19-2012
0

Re: Discussion on change url possibilities



stine wrote:

In your example, you used =cvs.   If the user shouldn't have access to this resource, you should block it.   If they do have access to it, why should it matter if they bookmark it using the non-obsfucated path?   If it's because you reserve the right to change the url ever two weeks and are tired of having to update your users' bookmarks, then you have a user problem.


Actually: I stumbled upon the fact that a user can change this value in the address bar and get somewhere. A value that they themselves should not be able to guess. I did not expect that an SA would allow this.
But I agree: blocking what they should not be able to see is best because they could get to the same place by following the links on other pages.
Contributor
Posts: 10
Registered: ‎04-19-2012
0

Re: Discussion on change url possibilities


zanyterp wrote:
The users are not changing the links; they are changing a value in their address bar.

While I understand what you are saying, there is currently no way to do this. The appliance is for secure access to the network & resources you define. It is not possible to control the browser; the SA system is not a new browser but a secure access gateway. I think the idea is great, but not something it does at this time.

Controlling the browser is not necessary. Controlling what is accepted in the SA is better.

Maybe something for a future version then.

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

Re: Discussion on change url possibilities

The control through the SA is the ACL; anything else is browser control.
However, it is an interesting idea that you can work with your SE about a feature enhancement
Contributor
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.


I've been thinking about the analogy with the file shares:

- suppose you create a share on a server: \\server\share.

- a normal user (not an administrator) changes the given share to \\server\users in Windows Explorer.

- what would you expect from Windows to do?

     1) grant access to the folder 'users' on the server with the ACL's you've set on the users folder? Even if the share \\server\users does not exist?

     2) Do not grant access at all.

 

Option 1 is what happens on the SA. Option 2 is what Windows does.

 

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

Re: Discussion on change url possibilities


minifig wrote:

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.


I've been thinking about the analogy with the file shares:

- suppose you create a share on a server: \\server\share.

- a normal user (not an administrator) changes the given share to \\server\users in Windows Explorer.

- what would you expect from Windows to do?

     1) grant access to the folder 'users' on the server with the ACL's you've set on the users folder? Even if the share \\server\users does not exist?

     2) Do not grant access at all.

 

Option 1 is what happens on the SA. Option 2 is what Windows does.

 



Unless you have an ACL allowing it, the same will happen on the SA and deny access, as it should as you have not given permission for that new location to be seen. Explorer/Windows _does not_ prevent the user from trying to conect to a different location in the address bar.

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

Re: Discussion on change url possibilities


zanyterp wrote:

minifig wrote:

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.


I've been thinking about the analogy with the file shares:

- suppose you create a share on a server: \\server\share.

- a normal user (not an administrator) changes the given share to \\server\users in Windows Explorer.

- what would you expect from Windows to do?

     1) grant access to the folder 'users' on the server with the ACL's you've set on the users folder? Even if the share \\server\users does not exist?

     2) Do not grant access at all.

 

Option 1 is what happens on the SA. Option 2 is what Windows does.

 



Unless you have an ACL allowing it, the same will happen on the SA and deny access, as it should as you have not given permission for that new location to be seen. Explorer/Windows _does not_ prevent the user from trying to conect to a different location in the address bar.


Well, the SA does allow access (see first post).

And the Explorer does not prevent the user from trying to change the location, but the server who holds the share does. You absolutely cannot access a directory on a server that's not shared. The SA allows you to get to websites that you did not define as bookmarks.

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

Re: Discussion on change url possibilities

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.

 

The bookmarks are just that: shortcut links to internal resources. If the user knows how to try and access other URLs by manipulating something external to the SA system, the browser address bar, there is nothing to restrict them from trying. The ACL you configure on the unit will do the actual allow or deny.

 

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.

 

that is an interesting point on that the IVE allows non-bookmark access (same as the hidden share path access in windows) and might be something that you should bring up with your account team to have an option created to enforce bookmark-only access. i do not know the feasibiity of this as there are items that rely on external manipulation of the URLs....but if this option was created, it would require specific enablement. i cannot think of a way that this could be done, but that does not mean it can't; only that I cannot, at this time, visualize a way that would allow this type of functionality.

 

in any event, the ACL for web access should restrict access only to where you want users to connect, regardless of how the user attempts to connect

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

Re: Discussion on change url possibilities


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.