From a security point of view, Python is better because it is less of a footgun. So if you expose an interface to untrusted users, you should use Python because its behavior is more intuitive. An arithmetic expansion or missing quotes do not easily become a vulnerability in Python.
Recently, I found a privilege escalation vulnerability in a shell script as a result of arithmetic expansion (similar to the one described at https://research.nccgroup.com/2020/05/12/shell-arithmetic-ex...). For example, $((1 + ENV_VAR)) allows you to inject code if you can control $ENV_VAR.
Unfortunately, shellcheck did not catch that. At least not with the default settings. But if you are implementing anything remotely security-critical, you should not be using shell anyway.
Now that it loaded again for me, I can see the /graphql endpoint. Caching GET requests to endpoints for a few minutes (or even just one minute) will likely suffice, given that the puzzle is the same for all users. If I am not overlooking anything, stats will lag behind for that period of time in the worst case. More info on how to configure nginx can be found on https://docs.nginx.com/nginx/admin-guide/content-cache/conte.... When a 502 error is served, images or bandwidth are usually not your problem but your backend that is too slow. In your case you probably only need `proxy_cache_path` to define the cache path, `proxy_cache` to specify the zone name you used with `proxy_cache_path`, and `proxy_cache_valid 200 302 1m;`.
Great puzzle. I liked it so much that I saw your message about going live a few days ago already.
Is there any dynamic content generation involved? I am wondering because the Gateway timeout hints at something behind nginx being the bottleneck. Don't you just serve static files? Maybe you could configure nginx to cache dynamic resources if they only change once a day or even consider turning dynamic resources into static resources by generating them once per day and serving them as static files.
I am not a brand ambassador or a living billboard and some random company is not part of my identity, which is why I dislike wearing t-shirts with company logos.
Interesting. I would still insist on not doing it that way, especially when writing a library for universal use. First of all, string replacement on structured input is an immediate red flag. Second, even if you get handling the structured input right by parsing the statement into an AST and replacing the leaves that are placeholders with the escaped strings, there are still potential vulnerabilities. For example, mysql_real_escape_string is still vulnerable when being used with some exotic character sets [1].
I don't know the internals of the (binary) protocol used for communication with the MySQL server though. Couldn't one just save the extra round-trip with length-prefixed strings by sending the query together with the parameters in a single message?
The problem is not only that types are not checked but that strings are simply replaced in structured input. Without having looked in detail, I would bet that the implementation also fails at queries which contain question marks inside strings, i.e. question marks that are not placeholders. Even if string escaping was the right way, which it is not, the proper way to do it would be to translate the SQL statement into an AST and then replace the leaves of the tree that are placeholders with the respective escaped strings.
I'd argue that the root mistake is that the server-side feature of prepared statements through the client/server binary protocol is not used as described in [1]. Instead, the question marks are replaced using a dirty hack. The whole point of prepared statements is that the client/server protocol takes care of inserting the values into the statement instead of having to fiddle with functions like mysql_real_escape_string.