#perform the inject test
root@oco:~$ BROWSER > {targetSite:port}
input field: 127.0.0.1; whoami
* the local IP address above represents the EXPECTED INPUT followed by the OS Command Injection payload (; whoami)
* write the expected input first then use any of the above operators, and then write the new command
* if the cmd doesn't work, determine whether the input validation trigger location
#determine whether the input validation is happening in the front-end or the back-end
root@oco~:$ BROWSER > {targetSite:port} > F12 > Network
input field: 127.0.0.1; whoami
* you'll notice that there are no new network requests were made when
the "check/submit" button was clicked, yet there's an error message received.
- This indicates that the user input validation is happening on the front-end.
- it is very common for developers only to perform input validation on the front-end while not validating or sanitizing the input on the back-end
- front-end validations are usually not enough to prevent injections, as they can be very easily bypassed by sending custom HTTP requests directly to the back-end
root@oco:~$ BROWSER > {targetSite:port} > CTRL + U
* reviewing the source page of the webpage...detected input validation on line 17
- <input type="text" name="ip" placeholder="127.0.0.1" pattern="^((\d{1,2}|1\d\d|2[0-4]\d|25[0-5])\.){3}(\d{1,2}|1\d\d|2[0-4]\d|25[0-5])$">
