This is a WORK IN PROGRESS. If you think something is missing or unclear then please submit an update or issue.

• This document contains a set of guidelines and gotchas that must be considered when hosting a Jobson server.
• The list is not comprehensive and does not cover every possible attack vector that could be abused: no realistic software developer can document that.
• These guidelines are not legally binding. Following them does not guarantee that you will not be hacked. All software has bugs and security holes that need to be patched over time.
• As with any security measure, take reality into account. If you are intermittently running a Jobson server on your home computer behind a router for a small home project then make a judgement call. Always ask yourself: "if a hacker started querying my jobs, running things, and maybe even breaching my scripts, how much damage would they do and how inconvenient would it be for me to fix things afterwards".

Network Security

These points are specifically about administering and securing the Jobson web interface. They assume you want to run Jobson on an insecure network (e.g. the internet) and you expect people to try and hack your server.

• Jobson is a standard webserver that listens for HTTP and websocket requests on a TCP port. By default, Jobson automatically binds and listens on all network interfaces on your server.
• Assuming a firewall is not setup, any client that can establish a TCP connection to your Jobson server can attempt to send requests to the Jobson API for jobs, specs, outputs, etc.
• Authentication and authorization determines whether a client actually gets a positive response to their requests. guest authentication will allow any client to use the Jobson API. Therefore, with guest authentication, anyone that can connect to the system can use the system. Non-guest authentication methods will reject requests that lack the required credentials.
• Jobson does NOT provide HTTPS connection encryption. If you are using Jobson over an insecure network (e.g. the internet) then you MUST provide an encryption layer over the bare Jobson connection. The recommended way to do this is to host a "user-facing" industry-grade webserver such as Apache/Nginx with encryption enabled and to configure that server to reverse-proxy incoming connections to Jobson.
• Realistically, Jobson will never be as secure as industry-grade webservers like Apache or Nginx. Following the above advice guarantees that your user-facing server is: a) extremely well tested against attacks and b) has many more guides for administration and maintenance. Server technologies evolve over time. Those webservers are regularly updated with security patches because people's jobs and lives depend on them.
• Encryption is not authentication. Any client that can establish an encrypted connection to your server can use the Jobson API subject to the authentication limitations outlined above. Properly securing access to a Jobson server requires both encryption (to prevent MITM attacks) and authentication (to prevent anyone from running things).

Securing Your Applications

• IMPORTANT: The top-line thing you NEED (as in NEED, NEED, NEED) to keep in mind is that clients are potentially providing inputs--either as arguments or files--to your application.
• Jobson will only check to ensure basic validation constraints such as "yes all the inputs are there", "yes, the input is a string" or "yes, it's one of the options".
• Jobson will also ensure that the correct arguments, as stipulated in your spec file, are forwarded to your application.
• HOWEVER, Jobson cannot magically guess what an attack on your particular piece of software is. If your job spec stipulates an expectedInput of string, Jobson--being as unintrusive as possible--will happily allow clients to provide:
  • Adam
  • ../../../../../../../../../etc/passwd
  • '; DROP DATABASE USERS;
• Therefore, if you believe users are going to be attempting to hack your software, VALIDATE AND SANITIZE YOUR APPLICATION'S INPUTS. This is true of every piece of software. Do not think that, because you're making Jobson run a big C++ application or a Haskell application rather than a "hacky" python script, you are automatically immune to these types of attacks. You aren't. Any technology that claims to automatically ensure that your software is ran with perfectly safe, sanitized, inputs 100 % of the time can only make that claim if they never actually run your software. Input sanitization requires an appreciation of how the inputs will be used which only the developer--you--can reliably do.
• Even if more validation + sanitization features are added into Jobson itself, you should probably still go through the effort of securing your application in case you want to use it outside of Jobson. Jobson is designed to be low-overhead and have minimal lock-in so that developers can use it when it suits them and dump it when it doesn't.

Jobson's Job Submission Security Model

The following are security measures are taken by Jobson before running your application.

• Job requests are not processed until the above network security measures are met. Clients that cannot connect to, or authenticate against, Jobson will will not be able to submit job requests.
• Job requests undergo the following steps before Jobson attempts to boot your application:
• The request is parsed using an appropriate 3rd-party parser (e.g. jackson for JSON requests).
• The parsed request is validated against your job spec to ensure that the inputs provided match the expectedInputs specified in a job spec. It should not be possible, for example, for a client to provide an invalid option for an option input or an array to a string input.
• At runtime, Jobson evaluates template strings in arguments (e.g. ${inputs.firstName}). Jobson will produce a fatal-error if evaluation cannot be done (it will not "limp along").
• There is a one-to-one correspondence between the number of arguments in your job spec and the number of arguments provided to your application.
• Jobson does not use a shell interpreter to run the specified application. It directly invokes your application using Java's Process class. This prevents shell injection attacks and guarantees that the arguments sent to your application are untouched by Jobson.