2 deleted 217 characters in body
source | link

What I'm doing:

I'm using OWASP Zap to find vulnerabilities in a site (I have the owner's consent) and Zap came up with a Reflected XSS Vulnerability after I did an active scan on a POST request. It told me that the variable "cn" (the username) was vulnerable to reflected XSS and that the payload "><script>alert(1);</script> would work.

My process:

I went ahead and tried to enter this into the input field called "cn". The input field had a maxlength of 12, I went ahead and did a quick inspect element it and changed that. Then I entered the payload, put in a random value for the password input field and clicked submit.

The Result:

Unfortunately an alert box did not pop up, just a wrong username and password message. I did notice that a little "> that appeared after inserting the payload. When I looked into this I found that the script tag had caused the "> to be parsed as regular characters. <input type="text" name="cn" size="20" maxlength="20" value="<script>alert(1);</script>"> is the html. The "> should not have modified the js though.

The Conclusion

UPDATE: So after thinking about this in the shower (Hey you know that all programmers and hackers do it!) I realized the whole point of reflected XSS... that the value provideprovides to the user had to actually be reflected back. The un parameter was never actually being reflected back to me. But this still doesn't answer the question... why did ZAP pick this up as a XSS vulnesrabitliyvulnerability when there clearly is not any XSS?

Also just FYI, I'm 13 and suck at hacking & programming. But I'm really eager to learn all of this and become a bug bounty hunter, so please be patient with me.

What I'm doing:

I'm using OWASP Zap to find vulnerabilities in a site (I have the owner's consent) and Zap came up with a Reflected XSS Vulnerability after I did an active scan on a POST request. It told me that the variable "cn" (the username) was vulnerable to reflected XSS and that the payload "><script>alert(1);</script> would work.

My process:

I went ahead and tried to enter this into the input field called "cn". The input field had a maxlength of 12, I went ahead and did a quick inspect element it and changed that. Then I entered the payload, put in a random value for the password input field and clicked submit.

The Result:

Unfortunately an alert box did not pop up, just a wrong username and password message. I did notice that a little "> that appeared after inserting the payload. When I looked into this I found that the script tag had caused the "> to be parsed as regular characters. <input type="text" name="cn" size="20" maxlength="20" value="<script>alert(1);</script>"> is the html. The "> should not have modified the js though.

The Conclusion

UPDATE: So after thinking about this in the shower (Hey you know that all programmers and hackers do it!) I realized the whole point of reflected XSS... that the value provide to the user had to actually be reflected back. The un parameter was never actually being reflected back to me. But this still doesn't answer the question... why did ZAP pick this up as a XSS vulnesrabitliy when there clearly is not any XSS?

Also just FYI, I'm 13 and suck at hacking & programming. But I'm really eager to learn all of this and become a bug bounty hunter, so please be patient with me.

What I'm doing:

I'm using OWASP Zap to find vulnerabilities in a site (I have the owner's consent) and Zap came up with a Reflected XSS Vulnerability after I did an active scan on a POST request. It told me that the variable "cn" (the username) was vulnerable to reflected XSS and that the payload "><script>alert(1);</script> would work.

My process:

I went ahead and tried to enter this into the input field called "cn". The input field had a maxlength of 12, I went ahead and did a quick inspect element it and changed that. Then I entered the payload, put in a random value for the password input field and clicked submit.

The Result:

Unfortunately an alert box did not pop up, just a wrong username and password message. I did notice that a little "> that appeared after inserting the payload. When I looked into this I found that the script tag had caused the "> to be parsed as regular characters. <input type="text" name="cn" size="20" maxlength="20" value="<script>alert(1);</script>"> is the html. The "> should not have modified the js though.

The Conclusion

UPDATE: So after thinking about this in the shower I realized the whole point of reflected XSS... that the value provides to the user had to actually be reflected back. The un parameter was never actually being reflected back to me. But this still doesn't answer the question... why did ZAP pick this up as a XSS vulnerability when there clearly is not any XSS?

1
source | link

How does OWASP ZAP find Reflected XSS?

What I'm doing:

I'm using OWASP Zap to find vulnerabilities in a site (I have the owner's consent) and Zap came up with a Reflected XSS Vulnerability after I did an active scan on a POST request. It told me that the variable "cn" (the username) was vulnerable to reflected XSS and that the payload "><script>alert(1);</script> would work.

My process:

I went ahead and tried to enter this into the input field called "cn". The input field had a maxlength of 12, I went ahead and did a quick inspect element it and changed that. Then I entered the payload, put in a random value for the password input field and clicked submit.

The Result:

Unfortunately an alert box did not pop up, just a wrong username and password message. I did notice that a little "> that appeared after inserting the payload. When I looked into this I found that the script tag had caused the "> to be parsed as regular characters. <input type="text" name="cn" size="20" maxlength="20" value="<script>alert(1);</script>"> is the html. The "> should not have modified the js though.

The Conclusion

UPDATE: So after thinking about this in the shower (Hey you know that all programmers and hackers do it!) I realized the whole point of reflected XSS... that the value provide to the user had to actually be reflected back. The un parameter was never actually being reflected back to me. But this still doesn't answer the question... why did ZAP pick this up as a XSS vulnesrabitliy when there clearly is not any XSS?

Also just FYI, I'm 13 and suck at hacking & programming. But I'm really eager to learn all of this and become a bug bounty hunter, so please be patient with me.