Many of us agree that LiveView is awesome. However, using WebSockets to power most of the application introduces new security challenges. For instance, with typical HTTP requests, developers can use Web Application Firewall (WAF) rules to block malicious traffic - major cloud providers often offer built-in tooling to support this. But once a WebSocket connection is established, the WAF can no longer inspect the messages being sent. As a result, malicious users sending harmful payloads can bypass the current security measures unnoticed.
In LiveView applications, we use functions like handle_event to process untrusted user input, which means these callbacks carry the same risks as handling an HTTP request. To address this, I quickly put together a proof of concept that introduces a LiveView lifecycle hook. This hook intercepts user-provided payloads and runs a detection model against the input to check for SQL injection attempts.
Warning, this is a massive proof of concept and there are really bad things in the source code and the solution is not generalized, but my goal was to quickly get my thoughts out into code and have fun. Now that its out I’d like to iterate and improve.
One final thought on my proof of concept: I don’t like solving this at the application level, but this was the fastest way to a working proof of concept. If we cannot solve it at the WAF level, maybe a websocket proxy is better than the application level?
I am curious for feedback and thoughts in general about this topic and maybe other creative solutions out there I am not aware of. Also, feel free to help improve the proof of concept (PRs are welcomed ).
IMO WAF and similar technologies are like resolving to only eat non-rotten garbage from the trash can; they’re ultimately a band-aid in place of a better fix that eliminates the root cause of the problem (ie, stop eating from the trash can).
For instance, the Potion Shop demo has a SQLi vulnerability - but only because the authors constructed an unusual situation where Repo.query is used with a raw SQL string interpolating using user input:
A general note on the repo: I was pretty bummed to not find any tests, as I was hoping to understand more about the specific sorts of things this tool is aiming to block by reading those tests.
I agree that WAFs should not be the only thing we use to protect our web applications and following secure coding practice is important.
The reason to pair a WAF and other security controls (like using the proper output encoding in this example) at the same time is to practice Security/Defense in Depth. In general this is a good security practice. What if there is a zero day in the output encoding of Phoenix that does not catch an obscure malicious payload? What are the impacts of that? How do I prevent my app from being affected by something like that? Seems unlikely, but you never know - stranger things have happened in our field. I should also mention, that while this proof of concept is focused on SQLi, I think a robust solution will be more generalized.
I could have added tests. However, this is a non-production proof of concept to start a conversation, not a proper library to be used by others. I have no intention of releasing this ever. If a better solution is figured out, I’d make a new project that has all the proper tests and builds running. For these reasons, tests did not seem necessary.
).
