Who's On?

	Membership:
	Latest: Saef
	Past 24 Hours: 0
	Prev. 24 Hours: 0
	Overall: 5226

	People Online:
	Visitors: 516
	Members: 0
	Total: 516

Name	Points
Greg Moeller	4184
David Williams	3349
JonA	3291
Kat V	2984
Woozy	1973
Jimmy Chiu	1883
Kwane McNeal	1437
Ragu Raghavan	1372
Roger French	1315
mark.cook	1244

Processflow - Inbasket Security Hole

5 Replies

2 Subscribed to this topic

52 Subscribed to this forum

Sort:

Author

Messages

MSUMikey

New Member

Posts: 1

12/2/2014 3:48 PM

We are trying to implement Pflow approvals, and we uncovered a bug where a user can access any other users Processflow Inbasket by manipulating a URL. They can then also approve Pflow work objects, and it appears as if the 'real' approver performed the approval.

Infor has acknowledged the issue and created the KB below and is developing a fix, but we do not have a concrete ETA.

My question is - has anyone else come across this in version 9 of applications, and does anyone have an alternative fix? Seems like this would impact anyone who does approvals in processflow for any purpose (Purchasing, Accounts Payable, etc) so I'm hoping maybe someone has found this and implemented their own solution.

KB article below, and step by step to replicate also below. Thanks!

https://www.inforxtreme.c...x?Solutionid=1576397

Step-by-step

1) In Lawson Portal menu on lefthand side of screen, right click on your name in Inbasket Processflow Integrator, and click “Open in New Window”

2) New window opens, with full URL at top. Change username in URL to any other Lawson user and press enter

3) The other users inbasket is now visible. You can now approve Processflow work items on their behalf, and it will appear as if the real approver was the one who clicked approve.

John Henley

Posts: 3353

12/2/2014 7:43 PM

- Depending on your requirements, I recommend using PF tasks rather than specific users for user actions. In addition to being able to change the owner of the next action, it also allows multiple users to act as an approver. And, inbasket does check that a user who is logged in is assigned to that task if they were to hijack the URL.
- I wouldn't expect a fix too soon since Process Flow is being replaced by Process Automation, which uses a completely different environment (LSF vs. Landmark) with different URLs, etc. However, your scenario does translate to a similar issue I encountered during the v10 beta, where Process Automation's "approve via email" would allow the same thing. It's simply a URL that can be clicked in the email with no authentication whatsoever...(:

Tim Cochrane

Veteran Member

Posts: 154

12/2/2014 8:08 PM

basically, what John said...

At my previous employer, where they've been running ProcessFlows for 14+ years, we've ALWAYS routed approvals (and sent PF emails) by Tasks/Cat Filters. We even went into the inbasket html and commentedf out the User link...not for security reasons, but because we didn't use it and it only confused people.

Start using Tasks from the beginning, it'll make your life easier in the long run

BarbR

Veteran Member

Posts: 306

12/11/2014 3:27 PM

We do use PF Tasks for UserAction nodes, but how have you used PF Tasks for HRUserAction nodes?

Kat V

Veteran Member

Posts: 1020

1/6/2015 3:13 PM

We found an issue with the url in the PF email notice. We were attempting to allow the users to approve from an email, but the URL was problematic. If the approver forwarded the email and the recipient clicked the link, PF logs the action under the approver's user id.

Has anyone managed to provide a "one-click" approval link?

Tim Cochrane

Veteran Member

Posts: 154

1/7/2015 9:14 PM

BarbR - we didn't use HRUserAction nodes, even for our HR people. The HRUserAction only allowed the option to escalate 1 level, which didn't fit our business requirements, so ALL approvals used the regular UserAction, that was supplemented by a custom escalation process to provide what the biz owners needed.