4 ms·
Isn't this only exploitable if you expose Kestrel to the internet? They (used to?) recommend to put a proxy in front of it so I would guess most deployments are
by yread 1y ago
Isn't this only exploitable if you expose Kestrel to the internet? They (used to?) recommend to put a proxy in front of it so I would guess most deployments are done like that
- GordonS 1y agoI don't remember exactly when, but I'm sure I recall Kestrel being declared production ready a few years back.
- qingcharles 1y agoYes, they definitely declared it production ready a while back. I use it bare metal exposed to the Internet and it works great. (TFA not withstanding)
- whizzter 1y agoActually, I think that a proxy might be a worse scenario in terms of exploitability. If the proxy that handles authentication has one notion of chunked encoding and Kestrel behind it has another notion and the proxy then shares it's connection between users, then an attacker might smuggle in a request to a high value endpoint. For example: - Kestrel serves an application with the endpoints /public_get_stats and /admin/change_user_rights - The proxy makes sure everything under /admin is authorized - An attacker does a POST request to /public_get_stats , the post is sent with CHUNKED encoding that the proxy interprets in one way thus letting it be passed to Kestrel - Kestrel behind it starts processing /public_get_stats but mis-interprets the chunked boundary leaving the parser to start the next (malicious) request, that in turn contains, a payload saying {"userid":"hacker","level":"superuser"} to /admin/change_user_rights