0

I was recently asked to try to solve a data integrity problem with a Filemaker database app that has been published to the Web.

This app collects job applicant data, through a series of views. There have been reports from a handful of users that during their experience using the app, they would see another applicant's data, while traversing through the application. It seems like these users all exceeded the session timeout threshold and then were revealed somebody else's data in the form.

I am looking at the JSESSIONID cookie that is being generated since that is the only link that I see between a browser session and the app. The JSESSIONID cookie is set to expire in the past and is of type "session"

The JSESSIONID values also seem incredibly similar; here are two JSESSIONIDS that I received when testing the app:

02442D0AA37DEF0512674E8C
02442D09A38288D712674E8E

Has anyone experienced a similar issue with Filemaker apps published to the web?

Is there anyplace else that I need to look besides at the way the JSESSIONID and Filemaker 11 relate? In other words, are there other known security vulnerabilities with the Filemaker Web Publishing engine that anyone is aware of?

With appreciation,

Slinky66

Slinky
  • 5,662
  • 14
  • 76
  • 130

2 Answers2

2

the JSESSIONID is set by Apache Tomcat. This software is bundled with FileMaker's Web Publishing Engine, but the session ID generation is not connected in any way with FileMaker.

Jesse Barnum
  • 6,507
  • 6
  • 40
  • 69
  • Sorry if I did not ask the question more clearly. There has to be some hook that Filemaker uses to relate the JSESSIONID cookie value in the client browser to a record in it's database and that's what I am attempting to understand. Also, the jsessionids are really similar but I thought that the jsessionid was generated by the method generateSessionId() (http://www.docjar.com/html/api/org/apache/catalina/session/ManagerBase.java.html#981) which creates very random strings – Slinky Dec 22 '11 at 18:38
  • Yes, you're right, although there is an indirection step in there - Tomcat (not FileMaker) relates the JSESSIONID cookie to an in-memory session object. FileMaker then reads and writes from that session object, and it is certainly possible that a bug could exist there which causes what you're seeing. – Jesse Barnum Dec 28 '11 at 02:55
0

I received notice from a Filemaker technical support member that there is a known, documented bug in Filemaker that is the cause of this issue. See these threads for more detailed information:

http://forums.filemaker.com/posts/0d29aeaea1

http://forums.filemaker.com/posts/ad61a7e781

Slinky
  • 5,662
  • 14
  • 76
  • 130