How to make this secure?



  • As part of our latest "quick" project, we made two apps.

    • a wordpress site where business users can log in and manage the web properties they have purchased

    • a node.js app that gathers and stores the stats related to these properties

    Wordpress app needs to reach out to the node app and get some stats, so it can render graphs for its logged in users.

    Normally, I would just have the wp backend communicate directly with the node to get this data. Unfortunately:

    1. The guy doing the wordpress app isn't exactly the backend programmer, and has no idea how to do that.
    2. I don't do wordpress
    3. We are under serious time pressure

    What I did for now is this:

    1. For each web property, wordpress app generates a long GUID-like key.
    2. On the frontend, jQuery makes an AJAX call (COR) to the node server using this key (so the key is visible to the logged in user)
    3. Based on this key, node.js server provides stats for a particular property
    4. jQuery renders the graphs on frontend
    5. We will do key distribution between the servers manually for now, maybe some automated process later on

    Node server doesn't have any kind of auth, the only security on that side is the obscurity of the key you need to provide (and https). Wordpress side is locked by the usual login.

    The api access is read only. The only bad outcome is leaking data from user A to user B, or to random 3rd parties.

    So, how secure is this? Is having this one random key tied to each property good enough, or do I need something fancier?


  • Discourse touched me in a no-no place

    @cartman82 said in How to make this secure?:

    So, how secure is this? Is having this one random key tied to each property good enough, or do I need something fancier?

    Seems good enough for now. Yes, getting the wordpress side to communicate directly with node side would be better (and is what you ought to be pushing for longer-term, especially as it is more architecturally correct too) but it's not a big problem as you're only letting the keys go client-side when someone has already logged in. That'll stop them from getting sprayed all over Google for a reasonable while. :)


  • I survived the hour long Uno hand



  • @Yamikuronue said in How to make this secure?:

    Does this thing help?

    Not really. I'm not touching the wordpress thing, the other guy is. If it was up to me, I'd make a custom website (and spend twice as much time, there's that).



  • @cartman82 How bad is it if your worst enemy sees those graphs (or, the data required to render them)?


  • Trolleybus Mechanic

    For more of teh security:

    1. Generate the GUID for a property / user combo, not just property
    2. Set an expiry on those GUIDs
    3. When a user hits the second site with the GUID, also auth that the user IDs match, and the GUID isn't expired

    That way, even if someone guesses the GUID, they still need to be logged in as the user (and/or steal their user cookie).



  • I'd think of this site-specific key as being analogous to a session key that might be used in a conventional secure system. With that, the basic idea seems secure enough, and the main concerns that I see are some of the deeper complexities that you may or may not have:

    Are there multiple logins for each web property? Do they get created and deleted, and by who? If not, can you be sure that there will never be? Because if there are, now or ever, then all users will have the same session key, so you don't know which specific user accessed the data when, and you don't have a good way to revoke access when a user quits or something.

    One fix would be to have the Wordpress backend call out to the node server, all right, but if that's non-viable, then the next best IMHO would be:

    Get the front-end script a user-specific token, and query to the node server with that, and possibly a site identifier too. The node server queries the Wordpress server somehow to validate that the user currently has permission to access the data for that site. This might possibly be doable with no extra backend code, depending on if the current Wordpress front-end has a way for you to get a user identifier, and if there's already a way to make some kind of call sequence to Wordpress with that user identifier that confirms that it is valid and currently has access rights to a specific site.



  • @blakeyrat said in How to make this secure?:

    @cartman82 How bad is it if your worst enemy sees those graphs (or, the data required to render them)?

    Hmm... as far as I can tell, it'd be little more than trivia. It's mostly just the visitation tracking data, like on google analytics.

    @Lorne-Kates said in How to make this secure?:

    For more of teh security:

    Generate the GUID for a property / user combo, not just property
    Set an expiry on those GUIDs
    When a user hits the second site with the GUID, also auth that the user IDs match, and the GUID isn't expired

    That way, even if someone guesses the GUID, they still need to be logged in as the user (and/or steal their user cookie).

    Since my node knows nothing about the wordpress users, this would require that the two sides be in communication in some way. So it's back to the initial problem of wordpress backend dev being limited to basicaly what pre-made plugins can achieve.

    @ufmace said in How to make this secure?:

    Are there multiple logins for each web property? Do they get created and deleted, and by who? If not, can you be sure that there will never be? Because if there are, now or ever, then all users will have the same session key, so you don't know which specific user accessed the data when, and you don't have a good way to revoke access when a user quits or something.

    That's a good point. I think, right now, it is implemented as one user account being "owner" of many properties. But who knows if this will change in the future.

    @ufmace said in How to make this secure?:

    Get the front-end script a user-specific token, and query to the node server with that, and possibly a site identifier too. The node server queries the Wordpress server somehow to validate that the user currently has permission to access the data for that site. This might possibly be doable with no extra backend code, depending on if the current Wordpress front-end has a way for you to get a user identifier, and if there's already a way to make some kind of call sequence to Wordpress with that user identifier that confirms that it is valid and currently has access rights to a specific site.

    Hmm, but generating special token per user session, token invalidation etc. All that seems beyond the capabilities of the wordpress side. :/


    Obviously, the way forward is to add some real backend code on the wp side.

    I'll probably end up doing exactly that. Since wordpress is basically just PHP + MySQL, nothing's stopping me from going around wp. Just plop a simple PHP script that digs directly into the database and use it as an API endpoint (https + simple auth should do it). Then implement daily access keys provided by my server or validate logged in sessions or whatever.

    Complicates things, but long term, I'll probably have to do something like that.


  • I survived the hour long Uno hand

    @cartman82 said in How to make this secure?:

    So it's back to the initial problem of wordpress backend dev being limited to basicaly what pre-made plugins can achieve.

    Right, which is what the thing I linked is meant to be doing: a plugin that makes WP act as more of an API server.


  • Discourse touched me in a no-no place

    @cartman82 said in How to make this secure?:

    Complicates things, but long term, I'll probably have to do something like that.

    Sounds right. If you're able to deal with the fools who think “working demo” = “working” then you'll be fine.


Log in to reply