shabiel / M-Web-Server

A YottaDB and Caché compatible HTTP server
Apache License 2.0
24 stars 19 forks source link

Security Hole: DUZ not properly removed for subsequent requests #4

Closed shabiel closed 5 years ago

shabiel commented 9 years ago

I discovered a security hole in M Web Server. It looks like if the DUZ is set, it remains set across subsequent requests. I did a test for this by creating a non-authenticated endpoint that first raises an exception if the DUZ is set upon entry and if not sets the DUZ to nonzero to see if the value sticks across subsequent requests. Sure enough, that is exactly what happened. I¹m addressing this by NEWing the DUZ in my endpoint, but you might want to look at this.

whitten commented 9 years ago

Do you have something like a session ID that could be checked ? I think you won't have any security if the DUZ was passed without authentication with every REST request unless you also passed the ACCESS CODE and VERIFY CODE with each request. This might make for a long URL but it would guarantee that the request is authorized.

shabiel commented 9 years ago

Actually, we do pass the access code/verify code for every request, depending if the web service you invoked requires that. In that case, DUZ will be defined. The issue is that if the process is recycled for another request, DUZ stays defined.

On Tue, Apr 7, 2015 at 9:27 AM, David Whitten notifications@github.com wrote:

Do you have something like a session ID that could be checked ? I think you won't have any security if the DUZ was passed without authentication with every REST request unless you also passed the ACCESS CODE and VERIFY CODE with each request. This might make for a long URL but it would guarantee that the request is authorized.

— Reply to this email directly or view it on GitHub https://github.com/shabiel/M-Web-Server/issues/4#issuecomment-90632791.

Sam Habiel, Pharm.D. VISTA Expertise Network

shabiel commented 5 years ago

VistA Signoff implemented in 178f9bd8a45a060d96795bbb93f57eb97ca7e4ca.