How I Found XSS By Searching In Shodan

It is just another XSS blog.

Anyways I was pentesting for a private program, I started with information gathering and meanwhile started dirbuster in the backend. I started with google and shodan. The moment I searched companyname.com in the search. A result appeared with a response in the shodan query. I opened the link and it was having an undeveloped WordPress page with a search bar. I entered XSS payload and it popped up. Then I changed the request method from POST to GET and it worked like charm.
We will assume that the website is https://companyname.com.

Description:

A code injection attack requires an attacker to enter malicious code (typically JavaScript or HTML) into an application in a data field that will be displayed to another user of the application. When the victim user views that data field, the javaScript executes in the victim's browser and can perform malicious actions. One common attack would be for the javaScript or HTML code to send the victims cookies to the attacker.

Impact:

The attacker injects a malicious javascript code or Html code in the vulnerable parameter/user search field. Here it was a reflected XSS, which was discovered by shodan query. This could be used to steal session token and cookie as it was part of the parent website which was running on the same server.

Steps to reproduce:

Search the companyname.com in Shodan.

Shodan Query Result

1. Visit URL:
   https://www.companyname.com/eiy/redacted?s=test
2. In the search bar enter the payload “><img src=x onerror=alert(document.domain)>
3. XSS alert popped up.
4. Proof Of Concept:
   https://www.companyname.com/eiy/redacted?s=%22%3E%3Cimg+src%3Dx+onerror%3Dalert%28document.domain%29%3E

Reflected XSS

Remediation:

To prevent data validation attacks such as cross-site scripting, I recommend a defence in depth strategy that includes both input validation and output sanitization.

The first step towards thwarting any data validation attack is to validate the input to prevent acceptance of any characters that may have special meaning within the application or the final destination of the data (in this case, the browser). The recommended way of handling input validation is to deny by default and only accept inputs that have expected values (i.e. a whitelist). Input validation routines should always check the data for length, range, type and format (perhaps using regular expressions).

Sanitization of malicious characters in the HTML served by the application is an equally important measure to prevent XSS. For instance, the character < would be encoded as < and, although appearing to the user as the less-than character, would not be interpreted by the client browser as the start of an HTML tag.

The best way to prevent XSS is to enforce output encoding, precisely Hex or URL encoding on user-controlled parameters which prevent the code to execute in the HTML page.

Reference:

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
http://www.softwaremag.com/L.cfm?Doc=1006-12/2006
https://www.acunetix.com/websitesecurity/cross-site-scripting/

Thanks
@justm0rph3u5