Re: Webservice Security

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

... is that the worst case is someone could discern
the protocol ...

Your biggest problem is probably malicious peope *with* access;
internal attacks are (in some ways) more common than external apps.

I always start web-service design under the premise that the protocol
(/api) is open, since it is trivial for people with access to a
genuine client to find out (even with metadata/discovery disabled).
Either by reverse-engineering your client (reflector), or by
installing the debug versions of the http libraries (available in the
platform SDK) that allow you to inspect the internals of ssl sessions
happening locally (at the client).

So since you must assume that the API is known (otherwise it is
[in]security through obscurity), the golden rule is never, ever, trust
the client; it is pretty easy to stick *any* home-built client on the
end of a web-service to which the user has geninue, legitimate access
- but which bypasses your normal process; submit an order for minus-
two-hundred PCs? No problem [big refund coming to someone]... Perform
a bulk update on 14,000 records? Sure...

Any security checks, business rule checks, and sanity checks *must* be
done at the server. You should also do them at the client, but this is
usually just a courtesy, and it makes the client more responsive if
you can immediately show an error message, rather than waiting on
latency for the server to say the same thing.

There are other scenarios relating to external attacks, but these are
much harder; Arne's points go some way to limiting your exposure here.
The only thing I can add is a good password policy (regular changes,
no repeats, strength-tested) so that people can't do something framing
"Jo whose password everyone knows is his kid's name". I know several
IT departments who actively and deliberately run some easily obtained
(and rather dubious) password cracking software on their corporate
networks: the aim being to ensure that your password can't be easily
cracked (by dictionary attacks etc). But good to see that even the
most nefarious tools can have legitimate uses!

Marc
Marc
.

Relevant Pages

  • Re: Pen-Test and Social Engineering
    ... (Real hackers will not care if they shutdown or DOS a server.) ... Time of the attacks. ... I once wardialed a client who ... Audit your website security with Acunetix Web Vulnerability Scanner: ...
    (Pen-Test)
  • Re: An argument AGAINST hosting your own email domain.
    ... the ISP for a client is currently hosting their email and we are bringing it ... the client should be receiving ... > system to 'auth attacks', NDR attacks, attacks which have yet to be ... get rid of your global mailboxes and set up ...
    (microsoft.public.windows.server.sbs)
  • Re: Client DDoS requests, ideas?
    ... This wasn't a question specific to any client. ... protocol & app attacks either weren't effective or the ... We're talking straight pipe vs. pipe DoS options. ... A mail server that uses spf could be attacked by creating HUGE spf ...
    (Pen-Test)
  • Re: Newbie needs drawing advice!!! Please Help!!!
    ... ASP components that do this probably install an ActiveX control on the ... application that ran as an activex that communicated with your web-service ... but the client would have to be running .NET. ...
    (microsoft.public.dotnet.framework.drawing)
  • Re: Pen-Test and Social Engineering
    ... War Games VS Hackers VS Bond VS Matrix?. ... Time of the attacks. ... I once wardialed a client who ... Audit your website security with Acunetix Web Vulnerability Scanner: ...
    (Pen-Test)