Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Suppose I have a web service used for increment/decrement uses' refos.

It may has these fields:

action: increment/decrement refos: 1000

The problem is, how can I know whether it's sent from firebug by a programmer or from my system?

I should respond to the action only if it's from my system.

The context is actually in a web game, where my system should increment the user's refos when some task is finished. But how do I deal with faking?

Replies are listed 'Best First'.
Re: A question about web service security
by JavaFan (Canon) on Aug 05, 2011 at 11:40 UTC
    The simplest way seems to configure the webserver so no request other than from "your system" can be made to said webservice.

    Otherwise, use some kind of authentication. There are thousands of techniques to choose from, many of them available in ready made source code, randing from simple and easy to use for the user, to very secure, and more hassle (work) for the user.

    What's the best pick for you, is impossible to determine from the post.

      Can you talk about the principle?

      I think there's no way to check whether it's from "your system" or not as HTTP is stateless,one can fake it easily.

        You could use a public key encryption scheme. Crypt::RSA would seem like a good start. Another option might be persistent sessions, CGI::Session might be worth a look. Sorry for the vagueness of the answer, but there isn't enough information in the original post to be more specific.

        2011-08-05 @ 1255Z Edited CGI::Session CPAN link

        No way? Uhm, that very much depends on your definition of "your system". And HTTP may be stateless, TCP certainly isn't (not that statelessness matters). In the simplest case, you have a network like this:
        ^-^-^-^-^-^-^ ^-^-^- +^-^-^-^ +-------------+ / \ +-----------------+ / + \ | Your server |===< Local network >===| Router/Firewall |===< Big Ba +d World > +-------------+ \ / +-----------------+ \ + / v-v-v-v-v-v-v v-v-v- +v-v-v-v
        So, treat a request coming from your local network as "your system", and if it comes via the "Router/Firewall", it comes from somewhere else. And you block it. Preferably at said Router/Firewall.

        Now, your details may be different, but your problem seems more a networking (and in particular, a firewall configuration problem) to me, than a Perl issue.

Re: A question about web service security
by dHarry (Abbot) on Aug 05, 2011 at 13:51 UTC

    As the context is a web game there is probably money involved. It really depends on how far you want to push it. I advice you to first write down your security objectives i.e. wat are your requirements? You probably need more than establishing who sent the message. (If authentication is the only thing you need you can for example do this with SOAP Headers.) Next you do some threat analysis, e.g. what threats are relevant for you? Then you can start thinking about implementation. If your users perceive the system as unsafe your game will probably be short-lived.

    With SOAs being all the rage, and WSs often being part of that, a lot of effort was put into security. I recommend scanning through the book "Improving Web Services Security" although this is MS based it gives a lot of useful information, e.g. architectures, security patterns etc.



      The entire process is that you play an interesting game, and there're many tasks in the game. Each time you finish a task, your refos will increment.

      It's impractical to interact with server side for every mouth movement/click in a mouth movement/click intensive web game...

        It's impractical to interact with server side for every mouth movement/click in a mouth movement/click intensive web game...

        Of course it is and I didn't suggested to follow that approach! I assume you keep some sort of state and after finishing a task communicate it to the web server.

Re: A question about web service security
by Anonymous Monk on Aug 05, 2011 at 11:44 UTC
    If you don't want refos incrementable by url, don't expose refos incrementor function by url
      However you expose it, it always can be faked IMO...

        Actually no. You can use a challenge/response technique. Take the MD5 hash of the current time plus some secret "seed", and send that to the client. Then, whenever the client requests that action, it must supply this MD5 hash. On the server side, you recalculate the hash for each of the last x seconds, and see if any matches what the client supplied. Only permit the action if the hash matches.

        The trick is to only deliver a hash to the client when it is a valid time to perform the action. And by restricting x to a small number of seconds, you control fairly tightly when the action can take place. So even if they do fake it, they can only fake it when it's a valid time to perform the action anyway.

        However you expose it, it always can be faked IMO...

        Um, the solution is to NOT expose it

        If its private data, only the server is supposed to modify, the solution is to only let the server modify it

        I think you need to explain the architecture of your application, draw a plain ASCII diagram or flowchart

        Think of the server as a bartender, who needs to check id, serve drinks, make change ... only bartender touches the cash register, customers always have to go through bartender, and he knows how to spot fake currency, fake ids, how much vodka is left ... bartender is gatekeeper

        See The Architecture of Open Source Applications

Re: A question about web service security
by sundialsvc4 (Abbot) on Aug 05, 2011 at 15:21 UTC

    This is both an authentication problem, and an authorization problem.   The request (of course) has to come from a properly authenticated subscriber.   But in addition, the incoming request must have been authorized.   For example, add some kind of token, whose contents are random, that must be returned by the client (in so-many minutes, and acceptable just once) with the request.   The server confirms that the token is authentic, issued to this user, and not-yet-used.   The presence of that token-value authorizes the request to be carried out.   The token, issued by the server and with totally unpredictable contents, can’t be faked, and once the server decides it’s been used, can’t be used again.