He1345
commented
4 years ago Nginx Vhost Traffic Status
update interval: sec
/format/json",vtsUpdateInterval=1000,vtsUpdate;var vtsStatusVars={titles:{main:"Server main",server:"Server zones",filter:"Filters",upstream:"Upstreams",cache:"Caches"},ids:{main:"mainZones",server:"serverZones",filter:"filterZones",upstream:"upstreamZones",cache:"cacheZones"}};var aPs=(function(){var a=[];var b={last:undefined,period:undefined};return{getValue:function(c,d){if(typeof a[c]==="undefined"){a[c]=d;return"n/a"}else{var e=d-a[c];a[c]=d;return Math.floor(e1000/b.period)}},refresh:function(c){b.period=c-b.last;b.last=c}}})();function mTh(b){var a=1000,c=60,f=cc,g=f*24,l="";if(b 
lagudomeze
vozlt
KiranXSingh
During a recent round of pentesting, I found a reflected Cross Site Scripting bug in the /status endpoint. Injecting javascript just after the /status endpoint e.g. /status> will trigger a JavaScript alert.
So far this has been triggered in both Chrome Version 78.0.3904.108 (Official Build) (64-bit) and Firefox 70.0.1 (64-bit).
I believe the introduction of headers such as CSP (Content Security Policy) and XSS block headers may prevent some Characters or payloads from triggering, however I believe a whitelist approach of allowed characters, filtering end encoding characters and proper input validation in the URL would help secure this. If it was locked down to only serve the content when expected input is submitted (Whitelist) e.g. /status/control?cmd=status&group=&zone= (but not accepting special characters as defined in rfc3986 https://tools.ietf.org/html/rfc3986) this would also help.
In this particular environment, is was able to access this endpoint with no auth. I used a payload which generated a JavaScript alert which used a benign payload of (1), but this could be used to redirect users to malicious sites, or maybe even exploit a users browser using the BeEF framework.