4

I am using a framework called VERTX to create an HTTP server. This is different from a traditional web server such as APACHE or NGINX. Here I will simply be using JAVA code to create a HTTP server which recieves requests on PORT 80 and send replies back, nothing fancy, very simple implementation. This is simply compiled into a JAR and executed inside of the command line where it will then listen for requests, that is it.

I will be running this HTTP server node (CentOS 7 or Ubuntu 14.04) on Google Cloud so there will be a Load balancer in-front where I can specify firewall rules (I will only allow port 80 to be accessed). The actual code just receives an HTTP request and sends back 'hello world' (no opening of any local files or anything). My question then is, if I close of all ports except port 80, run the HTTP server as another user besides root, are there any common (even uncommon) besides a denial of service attack which can be made on this server? If so, what would be a way to protect against these attacks?

Improve this question

2 Answers 2

Reset to default
4

A partial list of things to think about:

Do you support multiple connections at one time? What happens when you get a new connection request while another is pending? What happens if you get more connections than you're expecting? If you (or VERTX or Java, without your knowledge) dynamically reserve memory can too much be reserved (stack smashing: execute arbitrary code)? What happens if a client breaks the connection before you respond: do you properly clean up?

What happens if the client gives you too much or unexpected input? If you have a 1024-byte String to hold the requested URI but the client requests a 1200-byte URI, where do those extra characters go (buffer overflow) (not just the URI but any data the client gives you, like User Agent)? What happens if the client requests ../../../etc/passwd (path traversal; I know you don't intend to open files, but...) or non-ASCII characters (did you reserve 3 bytes because the string has length 3 characters, but they are all 2-byte unicode characters)?

Is there any sort of input that might get handled by the libraries you use in a way you don't expect (e.g. maybe VERTX sees a URL request for file:///etc/passwd and decides to handle it for you)? Or the opposite problem: are you close enough to the physical layer that you need to handle things like fragmented packets?

What happens if the client's IP address is spoofed to make you send replies to the wrong computer (relay attack)?

What happens when you decide none of these issues affect you now, then next year you use this platform as a base for another feature but forget to re-run your security analysis first?

Stretching your question a little: what happens to your users if the appliance is hacked by other means and your HTTP server is replaced with something that serves malware? Do you need to support HTTPS to protect your users? Presumably you have ssh enabled so you can manage the server (install new versions of your server, etc.): is that (or the console or whatever other method you use for maintenance) properly secured?

It takes a little bit of work to listen on privileged ports (below port 1024) without being root. You might make your life a little easier if you can listen on port 8000 (maybe have your load balancer redirect port 80 to 8000 for you).

Protection: defensive coding (like checking lengths of incoming data before copying it), know what's going on in the libraries you're calling, re-use already-debugged code, code reviews, static source analysis, testing.

Improve this answer
1
  • The stuff about string buffers being too small leading to arbitrary code execution does not really apply to Java. Buffer overflows are mostly a problem of programs written in C/C++. Java is more secure in this regard because all the standard data structures have automatic bound checking and the VM reliably throws exceptions when they are exceeded.
    – Philipp
    Sep 12, 2015 at 9:10
1

Generally speaking, the simpler the software, the less attack surface. The less code you have, the less room you have for bugs. So your tiny little webserver might be even more secure than a complex application like apache on nginx.

...might...

Critical security bugs can lurk in even the most simple code. Do you have such a bug? Maybe... Impossible to tell without reviewing your code, and even then there is never 100% certainty. You can only prove the existence of bugs, not the absence. There might also be unknown security vulnerabilities in the Vert.x framework or even the Java VM which are exploitable through your application.

So how do you protect against exploits of these bugs?

You can't. There is no way to protect against an attack scenario you don't know about.

Improve this answer

You must log in to answer this question.

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