1

Imagine that I have a server made with technologies and programming language that are not secure for some reason, such as legacy versions with known vulnerabilities or anything else that may result in giving a hacker an opportunity to forge an invalid request to access more data or internals of the system.
Now to solve the security problem instead of rewriting the core I would like to place the 2nd server in front of it. It should have libraries to be able to accept simple HTTP requests with headers, parse/generate JSON, do the validation (to ensure it passes valid JSON to the 1st server, i.e. recursively check structure, sizes and encodings) and so be quick, simple and safe enough to make is possible to rarely update it and use any unsafe protocol for easier communication with the 1st server.
What technologies should I use for the 2nd server? What programming language?

3
  • While the context is a security problem the question itself is mainly a programming question, i.e. which language is best suited to implement a particular programming task. This might be more appropriate at stackoverflow.com. And it will likely be opinion based. Commented Jan 25, 2020 at 12:14
  • What you describe is conceptually similar to a WAF. Be careful that such things are not (and cannot be) foolproof. For instance if the underlying application does not use prepared queries than your intermediary cannot fix that. It can only attempt to refuse requests with SQLi payloads, which requires blacklisting, which is rarely perfect. Commented Jan 25, 2020 at 17:57
  • @ConorMancone I imagine it as a whitelisting, not blacklisting. Like if I make sure some string in the JSON payload to match the /\Auser[0-9]{1,5}\z/ it would pretty much mean it's safe for me.
    – Nakilon
    Commented Jan 26, 2020 at 4:53

1 Answer 1

1

From the security standpoint any common programming language will do as long as you are familiar enough with it to securely code in it. Some languages like make this harder but often run faster, others make it easier at the cost of being slower. But the main point here is your expertise.

If your goal is to handle well-formed JSON with a fixed schema Go might be a useful language since it makes it easy to map JSON to structures with clearly defined types. This allows you to unmarshal JSON to a structure and marshal it back to JSON and implicitly normalizing and sanitizing the data while doing this. Go has also integrated support for handling HTTP and scales well. But there are likely libraries for other languages which provide similar support and it might be better to use the language you are deeply familiar with instead of learning a new one.

3
  • 1. The reason I don't want to hurry with implementing it in the language I have the most expertise is that it does not need all the features of my language. Intuitively, simplier technology is more rare to be compromised. 2. What do you mean under "a structure"? I don't want this server to know much about my objects. Only validate headers as key-value strings of limited alphabet and size and JSON payloads for being a pile of strings of limited variety of size and nesting, etc.
    – Nakilon
    Commented Jan 26, 2020 at 4:44
  • Conteptually I want to match some sort of validating regular expressions to incoming requests by using as much simple and tested technologies as possible.
    – Nakilon
    Commented Jan 26, 2020 at 4:54
  • @Nakilon: If you want to have your server properly validate your JSON you should define the schema and types for this - and this can be done in Go by simply defining the structure and maybe some mapping of keys and the rest will be done automatically. If you just want to have some regex pattern matching Perl with regex as 1st class language feature is still nice and has also support for HTTP and JSON. But beware that regex are a very complex language feature with many pitfalls (like wrong regex or regex complexity attacks) by its own. Commented Jan 26, 2020 at 6:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .