Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Oracle Web Application Server

Re: Oracle Web Application Server

From: Tommy Wareing <p0070621_at_brookes.ac.uk>
Date: Thu, 30 Jul 1998 10:19:58 GMT
Message-ID: <35c04476.508471283@news.brookes.ac.uk>


On Wed, 29 Jul 1998 15:33:58 GMT, russ_at_u-net.net (Russell Fray) wrote:

>
>Hi,
>
>>1. Normal web Form which prompts for username and password.
>>2. Lookup username and password in password table and verify.
>>3. Set a cooky with the users ID.
>
>That's very dangerous though ... the method described in the last post
>worked a treat and very simply. Not wanting to sound rude and I do
>appreciate your post, but I really would recommend having a look at
>re-writing the OWA_INIT package.

Oh boy... replacing an Oracle supplied package. D'you have any idea how hard it's going to be to get support after that? And you need to change it again after every upgrade.

That doesn't mean it's the wrong way to do it... it just causes some problems.

>
>The method you describe could very easily be monitored using a packet
>sniffer.

And the basic authentication can't be sniffed?

> If you are using cookies it sounds like you are completely
>intranet, hence it's not too bad, but my DB is going to be accessed by
>25,000 users from around the world via HTTP, hence I needed the basic
>HTP authentication system :)

I suspect...
basic authentication may be spoofable: whenever you go to a site which wants a password, the browser sends the CURRENT username and password, which may be accepted, or not. If not, then it pops up a dialogue and asks for new username password. If somebody hacks their server to demand a username and password, and then accept them whatever they were, they can collect quite a set.

If I'm wrong, please let me know, 'cos I've been worried about that one for a while...

What we do:
Normal web form asking for username and password, which sends back via https (secure sockets layer).
If the pair is valid, generate a session id, and send that back as a cookie (or include in the URL if the user doesn't accept cookies). The cookie has no expiry date, so it's never stored on the users machine (it dies at the end of the session).
Also make a note of the user's IP address.

First thing we do in all code is check the session id (either as a parameter, or as a cookie), and validate that it comes from the right IP address.

I can't think of any security holes in that that don't apply to other models too... and it does cover the problem I mentioned above (if it exists...)

--
Tommy Wareing
MIS Group
Learning Resources
Oxford Brookes University
01865 483389 Received on Thu Jul 30 1998 - 05:19:58 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US