What kind of vulnerabilities to consider when using LiveView?

I’m curious what kind of malicious scenarios should be considered with LiveView. LiveView transfers computation and state to the server, which seems to open up attack surface. For example, if a client cannot/will not receive messages fast enough, that increases memory usage on on the server?

3 Likes

Every websocket connection that liveview uses is a single process. Processes have (as per current documentation) 327 words of memory allocated to them, if you exceed that threshold the process crashes and the memory is freed.

The exception is when it comes to things like big binaries, those are stored in a different place and referenced from the process. This is a possible vector of attack as it is possible to create memory leaks with binaries that are not garbage collected correctly, but at the same time this is trivial to fix if detected and it highly depends on the implemented logic.

1 Like

This answer, as I read it, is potentially misleading. The heap of the liveview process is not constrained to its initial size during its lifetime, but may grow.

Regarding denial-of-service attacks, this would depend on how the underlying HTTP adapter (cowboy or bandit) managed flow control over the underlying socket, but if you wanted to be conservative, you could set your own heap limit.

My bad, the number above points to the initial heap size allocated. The maximum heap size for a process is (or at least can be) limited nonetheless, with the max_heap_size option:

{max_heap_size, Size} - Sets the max_heap_size process flag. The default max_heap_size is determined by command-line argument +hmax in erl. For more information, see the documentation of process_flag(max_heap_size, Size).

2 Likes