Once you hook an admin with the cross site scripting, you can now exploit the remote code execution as if you are the admin by executing javascript in the admin's browser, and from there you can likely get a reverse shell. Remote code execution is when you can run code on a system that you don't own. If you can find a cross site scripting vulnerability in a user area, you can upload a payload there (maybe even a payload similar to what I outlined in 2), and search for a remote code execution in the admin area. (This is also outlined in plast1K's answer) Some websites have admin and user areas.You're still held within the browser's sandbox, but you get an interactive javascript session which is neat. In your exploit code, you can have a loop that makes a request to a server you control, wait for the response, and eval javascript code included in the response from your server you would also need to set up a server where you type some javascript code for it to be executed in the victim's browser.
However, you can still get a reverse shell of sorts. A web browser executes javascript in a sandboxed environment so it is generally difficult to escape that sandbox.
Cross site scripting is when you can execute javascript in a victim's browser, generally on a site that you don't own.
Likely, you could even get a nodejs reverse shell where you have the same capabilities as a netcat reverse shell, but it doesn't require netcat to be on the exploited system. If you broaden cross site scripting to mean "Javascript code injection", then it is possible to get a reverse shell if a server is running nodejs. A netcat reverse shell runs on a system, whether it's a server or an end user's computer.Below, I'll give 3 alternatives that are only slightly different from what you asked. However, as others have pointed out, they cannot be combined as the question is stated. Plast1K has the best answer learn about each individually as it will help you understand if/how to compose them.
0 kommentar(er)
