Previously, I wrote about SSL and how Weblogic utilizes it from a server perspective. This article provides a followup analysis from a client perspective, the client being the PeopleSoft system. We will look at a few examples of different client uses in PeopleSoft and how we can control the protocol used.
As previously mentioned, I was doing an analysis of how PeopleSoft and Weblogic utilize SSL which was spawned by the announcement of POODLE. I’m going to review my findings for Weblogic 10.3.6.x and then duplicate the analysis to see if anything is changed with Weblogic 12.1.2. Weblogic 10.3.6.x is supported for any PeopleTools 8.50 – 8.53 installations. If you are on an older release of Weblogic 10.3 you should upgrade your Weblogic. Continue reading
POODLE has been a fairly common topic with security teams recently since Google announced the vulnerability.
There is plenty of reading available on the POODLE attack so I’m not going to go into too much detail but I’ll give a short description. POODLE is a man-in-the-middle attack which uses an attackers ability to force the protocol of the server/client communication to fall back. When the attacker can force the downgrade of the protocol to SSLv3 they can attack the weaknesses of that protocol. SSLv3 has been around for a really long time, since 1996, and has been superseded by multiple versions of TLSv1.x. TLSv1.2 is the latest version available and TLSv1.3 is currently in draft status. As these new TLS versions were released they were implemented in new servers and applications, however for interoperability all the old protocols were also left active.
So are you vulnerable? As a PeopleSoft Admin/User/Developer do you need to worry about this? Well, that depends. Continue reading
There have been several PeopleSoft Timeout problems that have impacted various levels of 8.50, 8.51, and 8.52. Indications are all these problems are fixed now. According to Oracle, the code has also been fixed in 8.50.25, 8.51.17, 8.52.07, and 8.53. I’m sure a new problem will pop up at some point though.
The first problem which I consider the most dangerous, is that the timeout warning process breaks down and causes a users browser to repeatedly request the timeout warning pop-up page. It looks like this particular problem impacts 8.50.22, 8.50.23, and 8.50.24. It looks like it also impacts 8.51.12 – 8.51.16 and 8.52.00 – 8.52.06. I don’t have the 8.51 or 8.52 versions running, however looking at the code delivered in the 8.51.16 and 8.52.06 patches, the problem code does exist. I know 8.52.07 does not have the bad code because I do have access to an environment at that level. This was actually put in as a fix for another problem, which I’ll mention later. It was put into 8.50.22, 8.51.12, and 8.52.00.
Users may have their PC’s hang as the browser takes CPU to 100% requesting the timeout warning page. Or if you have access logging turned on and you review the web server access log you will see hundreds to thousands of requests for the warning page from a single IP repeatedly in quick succession. In some cases this can cause the web server to crash. In other cases I’ve heard of it maxing out jolt connections on the app server. Oracle has a work around posted [ID 1405219.1].
Another problem is that time outs across windows/tabs are not synched. This one I think has existed for a long time actually. Oracle indicates that there was a bug in 8.4x that they did not fix which allowed users to not be timed out of idle windows but since it was a bug, it was fixed in the 8.50 release. I’m not sure what 8.4x releases that bug impacted. Good news is it’s fixed moving forward. Oracle says this about the behavior.
In PT8.4, if end user is active in one browser window, but lets the other window remain idle and timeout, the end user could continue in active window. This was a bug: 11558697 in PT8.4 and incorrect behavior. Many customers prefer the incorrect behavior in PT8.4; however, that behavior was a bug. The timeout behavior in PT8.50 is correct and development will not revert back to PT8.4 timeout behavior.
I was doing an assessment of a Peoplesoft installation recently when I noticed that the node passwords were the same across all environments of the same application type. While this might not seem like it is a big deal, it can open up a production environment to unauthorized access or accidental data entry. If this sounds like your environment perhaps some of your developers or users may have already realized that this allows them to access production with out a password from a non production environment, especially if they use bookmarks or direct URLs.
The problem here is related to a mechanism of Peoplesoft’s authentication. The PS_TOKEN cookie which is used for authentication is created from among other things the issuing systems default local node and password. If this data is the same across say, all your HCM environments, then a PS_TOKEN created in a development environment can also be valid in the corresponding production environment.
My recommendation is simple enough, force the node passwords to be different for every database in your install via your refresh script or process. This will ensure the PS_TOKEN is not valid across multiple instances of the same application and prevent this rather undesirable “feature” that I know several developers have enjoyed and even relied on in the past.