Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

SOAP::Lite - securest authentication route...

by cLive ;-) (Prior)
on Apr 20, 2004 at 01:36 UTC ( [id://346503]=perlquestion: print w/replies, xml ) Need Help??

cLive ;-) has asked for the wisdom of the Perl Monks concerning the following question:

Being paranoid, I'm working on locking down access to a SOAP server. So far, I've got:
  • HTTPS only
  • Basic Authentication
  • IP restrictions

So basically, only requests from the correct IP addresses with the correct authentication over HTTPS get through. But I'm wondering if that's enough :)

The system needs to be flexible enough that it can easily be expanded, but security is definitely a priority over flexibility.

The other method I thought of (dropping the Basic Authentication) was:

  • keep list of valid MAC addresses in DB on server
  • on initial request, send challenge string
  • client appends to MAC address and creates MD5 hash
  • server confirms this by looking up expected MAC address for that IP and sets a session cookie with client (another MD5 hash, restricted to particular IP in DB table server side, confirmed with each request and with 15 minute session timeout)

Or am I approaching this the wrong way? Searching on this I haven't found any advice over use HTTPS and basic auth...

cLive ;-)

Update: to avoid confusion here, all clients are servers we have control over. I'm leaning towards creating a local Certification Authority and SSL certificate authentication - This article looks promising. Thanks for thoughts so far :)

Replies are listed 'Best First'.
Re: SOAP::Lite - securest authentication route...
by Fletch (Bishop) on Apr 20, 2004 at 01:48 UTC

    Keep in mind that MAC addresses will only be available for machines on the same physical network segment as you, so unless this is just intended for use on a single LAN that'd be heading down the wrong track.

    A much better solution would be to use SSL/TLS certificates to strongly authenticate clients.

    Update: Also note that it's not impossible to spoof another host's MAC given the right OS and a cooperative NIC. Granted they'd have to knock the real host off the network or it'd probably send packets with RST set when it sees traffic for TCP connections it knows nothing about, but traffic from a given MAC doesn't guarantee it's from that NIC.

      Good point. Most clients will be on the same physical network segment, but some will not be. Hmmmm. /me goes off to read up on coding SSL certificate authentication...

      cLive ;-)

Re: SOAP::Lite - securest authentication route...
by exussum0 (Vicar) on Apr 20, 2004 at 02:15 UTC
    If you are using SSL, why not use HTTP-Auth plus signed certificates? Only accept certs signed by a single parent cert?

    Set them to expire every so-many-months, and filter by signer if you need to ban someone who is abusive.

Re: SOAP::Lite - securest authentication route...
by sgifford (Prior) on Apr 20, 2004 at 01:55 UTC
    Your outer layer of security sounds fine. You should also make sure that:
    • Your application is secure. The application should be very carefully written, should use taint mode, etc.
    • Your server is secure. Make sure other services are locked-down, it's probably behind a firewall, running only necessary services. You should be running a secure operating system, probably some kind of Unix. Also make sure you have a procedure for regularly updating the installed components of your OS, such as Debian's apt-get or RedHat's up2date.
    • Your network is secure. Your router and switches should be reasonably well-protected, etc.
    • Your clients are secure. Make sure they're running secure OS's, if possible, and are regularly updated. If one of your clients is taken over by the latest virus and an intruder gains access to the keyboard and screen of the machine, all of your other security is worthless.

    If you want to do MAC-level filtering, it's probably best to do that at the OS/firewall level; that information isn't readily available to a userspace program. Of course this will only work for machines on the same LAN as you, and users can change their MAC address, so this doesn't add too much.

      While I agree with the rest of your post, I want to comment on your last point:

      One should never assume the clients are secure. Always (if at all possible) treat clients with utmost suspicion, and that means not trusting any data you get from the clients unless it checks with the stuff you know. Taint checking all the input should go without saying.

      Assuming the client is out to get you not only protects you from clients that have been taken over by black hats, but also from bugs in the client...

        I agree that the script should never assume the client is secure, as an essential component of a security-in-depth strategy.

        However, a secure client really is necessary for making sure only authorized users use the script. A compromised computer may be under an unauthorized user's control, but have a permitted IP address and access to the password or the SSL certificate.

Re: SOAP::Lite - securest authentication route...
by gnork (Scribe) on Apr 20, 2004 at 09:18 UTC
    I'd like to extend that security model in a way to control access to the methods of the SOAP-Server based on either (lets say) userid, hostname or even a kerberos ticket.

    I did a bit UTSL in SOAP::Lite and so far I was not able to determine a point in the code to place this extension. One idea would be to overload the "dispatch_to" method of SOAP::Lite.

    What do you think, is it worth the effort?

    Rgds,
    Gnork

    cat /dev/world | perl -e "(/(^.*? \?) 42\!/) && (print $1))"
    errors->(c)
      I have a feeling that grabbing the Apache request before it hits the SOAP stuff through a PerlHandler) would be the easiest way of doing that. Although that's not how I'm currently approaching it :)

      I was going to add a 'LocalAuth' module (or similar) that would be run at the beginning of a method call, something along the lines of:

      if ($auth->can('set credit card')) { proceed(); }

      as the final lock down at the application level, where individual methods are listed in a DB along with identifying group(s) of hosts allowed to run them (then do a group look up to see which group the particular host belongs to.

      I'm still in flux over all this, but having great fun experimenting :) Perhaps you'd care to expand on your ideas...

      cLive ;-)

        The DB solution is exactly what I have in mind. The "$auth->can" call in the method call is one solution I thought about.
        Since this requires an additional call in the method code, I would opt for an inherited method or an additional module in SOAP::Lite, that does this work.

        Gnork

        cat /dev/world | perl -e "(/(^.*? \?) 42\!/) && (print $1))"
        errors->(c)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://346503]
Approved by Steve_p
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (6)
As of 2024-03-19 03:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found