Resolved [PPP-13862] Redirect on automated login and http referrer

[Krzysiek_Pisz]

Hello,

I'm trying to redirect users to database/mail management pages with automatic login link, while logging in part works ok, I have issues with redirections.

Plesk is installed on different server than my site, and if I try to use "success_redirect_url" param in link url, it will show this error "Original link and target URL should be on the same domain."

It works ok if I prevent browser from sending http referrer to plesk, but I'm not sure if it will work for all user as this depends on their browser.

Is this a bug? Is there a workaround that would not depend on used browser?

 

[jovana]

I have reported this bug / feature already back in October 2012. Because this same error also exist on Plesk 11 using the /login_up.php3 parameters.

For example:
<form action="https://<server_address>:8443/login_up.php3" method="post" target="_blank">
<input type="hidden" name="login_name" value="user" />
<input type="hidden" name="passwd" value="password" />
<input type="hidden" name="locale" value="nl" />
<input type="hidden" name="success_redirect_url" value="/smb/database/webadmin/id/1" />
</form>

This was the answer I got back in 2012:

<qoute>
Hello Joël,

Behavior which allows to access internal addresses thru "success_redirect_url" option from other sites , was considered by Plesk Service team as a security breach.
And that security breach was closed in last versions. That why it does not work at your servers.
Currently we have no workaround for this issue, because it was disabled by developers intentionally.
As I mention before, based on your request I have created feature request to Plesk Service Team #1496087 about necessity of function similar to disabled one.

Further discussion about this request will be with Service Team directly, and will take place in new ticket.
Thank you for your time and collaboration.

Best regards,
Dmitriy Bardakhanov
Technical Support Engineer
Parallels
</qoute>

 

[sebgonzes]

Hello,

Firstly, sorry for my bad english :-S.

I have bougth an ticket support for this bug (it's not a bug for parallels support), after 4 days, more than 11 answers and 6 technical of Parallels, they have give me an bad solution without guaranty, and of course, they said that there is not posibility of refund because it's an script problem (75$) !!!!

"For the (work around / tweaked version of script) which I shared with you, I don't give any guaranty that it will work in all scenarios. Also, it may stop working in case our Plesk Service Team finds it as a breach and disable it via patches. You may use the script at your own risk."


"This option is described in Advanced Guide in order for you to understand the paradigm of the session working, however as it is said there, some of the methods we do not recommend to use, so if you want to use such potential phishing target - feel free to, but with the extra precautions. Let me point out again, that the documentation you refer to is not API Guide, which can be found here: http://download1.parallels.com/Plesk/PP12/12.0/Doc/en-US/online/plesk-api-rpc/ , but Advanced Admin Guide. However, although the link that is stated there is working perfectly fine, the only thing that it is being called incorrectly. Thus I can claim that it is due to improper redirect call."

So, there is an parameter of API, that they recommand not using it, they don't give any good instruction, and when there is an panel control error, is the customer script improper use....

No more comment, this is the parallels support.

 

[pleskpanel]

It sounds like you're asking Plesk to re-enable a possible injection point in their control panel and it's not likely that this will happen since it's not really a bug. Plesk documentation is another story but at the very least you can appreciate the fact that Plesk is looking out for the majority of their user base by disabling redirection at the login screen using the technique that you want to.

 

[sebgonzes]

Hi
If it's really an security problem, why this parameter still active in API and documentation?

 

[pleskpanel]

My guess is as good as yours - Either Parallels is leaving the door open for a better solution in the future or they haven't gotten around to cleaning up the API and the associated documentation

 

[sebgonzes]

The problem is that parallels team have not disabled this parameter... and It's not working with chrome (with no way), but yes with IE (last version) and Firefox (last version) only using an special way of redirect (other way don't working)... But if you contact support to use this parameter that still active, you had to pay 75$, and they saying it's out of scope, and not refund the ticket.

It's really normal this situation??

I understand that :
- If it's exist this parameter, it had to work in all of navegador
- If it is a bug, it's on scope support and have to solve it...
- If it's really out of scope (I don't think so), but in documentation and not working, almost they had to return fund of ticket...

As you know, better not using support if you had an problem, because it's possible to have no solution to problem and lose 75$!

 

[IgorG]

Do you have support ticket ID? I would like to check it. Thanks.

 

[sebgonzes]

Hi Igor, ticket id 1989894, hope that you can help us to solve problem...

 

[IgorG]

We have discussed this problem in our team. Issue will be forwarded to developers for deep investigation. I will update this thread with details as soon as I receive them. Thanks.

 

[IgorG]

Guys, this is a bug that we've fixed in 12.1 (removing frames from 12.1 UI has really helped with the fix, BTW). ID of this bugreport - PPP-13862 for your reference.
You can check it on our latest 12.1 preview build.

 

[sebgonzes]

Hi Igor

I have upgrade to plesk 12.1.18, and still have the bug with chrome (Almost, now, the error appear in panel control and not with blank page and error in logs panel)

The same test work perfectly in firefox.
I can give you access to what you need to review it....

 

[SibProgrammer]

Are you sure you use the same domain for request and "success redirect url"?
Can you try to reproduce the problem on a93-91-167-251.ec.parallels-summit.com (admin / panel)?

Here is an example of the URL:

https://a93-91-167-251.ec.parallels-summit.com:8443/enterprise/rsession_init.php?PHPSESSID=22958cc09fd584faa0e9538232004e86&success_redirect_url=https://a93-91-167-251.ec.parallels-summit.com:8443/admin/subscription/list

It works for me.

 

[sebgonzes]

Hi

Yes, we use same domain name in success redirect url parameter (I have not put it for privacity reason).
Can you test this http://193.42.143.105/testplesk.php in Chrome (give error) and then in Firefox (work fine)?

 

[sebgonzes]

Hi SibProgrammer/IgorG, any update about this?

 

[websavers]

I'm also hoping for an update on this. I'm attempting to build better integration between our billing system and Plesk, but I'm unable to deep link into any useful areas during either simple login_up.php3 POST authentication or via rsession_init.php. I get the exact same error as described above by sebgonzes.

I can't see how this is a security risk in that after getting the error, I can simply click on anything on the page to bring up my subscription details... it's not like it's actually preventing access to anything, it's purely preventing the behaviour from being what is expected. At absolute best it's security through obscurity.

Not to mention that if you're using the API and rsession_init.php to resume the API session manually, the authentication is already completed and you've already got full access to whatever user-level your API session was created with.

This is while using Plesk 12.5.30 Update #12.

It's important to note that this will work fine when testing manually by copying/pasting the URL into the browser, then logging in by manually entering your username and password, since the HTTP referrer is set on the login page. It's when attempting to both login and redirect in one shot that it fails.

Also, if this functionality is to remain broken purposefully, then the error is poorly worded in that it's indicating that the original link and target URL need to be on the same domain, when in fact it appears to be comparing the previously viewed page URL and the target URL / success_redirect_url.

-Jordan

 

[websavers]

Are you sure you use the same domain for request and "success redirect url"?
Can you try to reproduce the problem on a93-91-167-251.ec.parallels-summit.com (admin / panel)?

Here is an example of the URL:

https://a93-91-167-251.ec.parallels-summit.com:8443/enterprise/rsession_init.php?PHPSESSID=22958cc09fd584faa0e9538232004e86&success_redirect_url=https://a93-91-167-251.ec.parallels-summit.com:8443/admin/subscription/list

It works for me.

Any updates by Plesk devs on this? Last we heard from SibProgrammer above indicates that they believe it is fixed, but it doesn't seem to be! I would like to know if perhaps I'm doing something wrong, or if this issue really does continue and as such the Plesk internal development tracker should be updated to indicate that further development / repairs are necessary.

I should note that some people above indicated that this functionality might have been browser-specific, but I tested with Safari 9.0.1, Firefox 43 b8, and Chrome 47.0.2526.73 beta (64-bit) all on OS X and encountered precisely the same error across all three.

-Jordan

Update: I have opened a support ticket on the matter and the first-line support rep has reproduced the issue internally. It has been passed on to devs to investigate further.

 

[websavers]

A Plesk developer responded indicating that any such use of the success_redirect_url *must* be set up on the same domain as that which the server is being accessed. So for example, if your Plesk URL is https://plesk.myserver.com:8443 you could set up a redirect.php on https://plesk.myserver.com that grabs the variables and feeds them through to Plesk on :8443, but you *can't* do that very same thing from any other domain.

They also indicated that the reason for this is because "This approach helps to protect Plesk against phishing attacks."

But I don't really understand how that's true. It's obscurity moreso than security, no? If we can change the "Referrer" value with the right browser plugin in order to bypass this check, then so too could any malicious user. Additionally, for the success_redirect_url to work, you must already be authenticated either by rsession or by standard login. Either way you've provided valid access credentials. Perhaps I'm just not thinking of the correct attack vector here; could anyone elighten me as to how this is *actually* a security feature other than simply draping a sheet over your door and hoping nobody realizes there's a door there?

-Jordan

 

[websavers]

Good news, this is fixed in Plesk Onyx! success_redirect_url works.