It seems to me that you struggle with the following question: "How does the attacker trigger the victims browser to send such a request?"
- In the URL. You mention that you understand this version, so we can work from there. The attacker crafts a URL that he send to his victim. This can be a simple link, that the victim clicks on, or some kind of redirect from another website. When the victim clicks the link, a GET request is sent with the payload, the server embeds it in the response, and the browser executes the malicious script.
- In a cookie. This seems tricky at first, because you cannot set a cookie for another domain in the victims browser. But that is already the solution to the problem - it does not work usually. What you need is a special use case, that allows you to set the vulnerable cookie through a mechanism in the website. Imagine a cookie that defines the language of the website. The website could implement a simple request that allows the user to store his language preferences in a cookie, allowing an arbitrary value. The server answers with a
Set-Cookie response header containing this user defined value. This arbitrary language value is stored in the browser and sent as cookie with every future request. If the website is vulnerable to XSS, meaning it reflects the cookie value without sanitation, an attacker can craft an easy attack by forcing the browser of the victim to send two requests. The first one will store the cookie payload in the browser, the second one will be another request to the website, where the cookie gets reflected.
In the end, the concept of XSS stay the same in all three scenarios, only the attack vectors look slightly different. Providing specific user input, as you requested in your question, doesn't make sense though, because the payload is always the same. If you can do it with a GET parameter in the URL, you can do it with any other form of user input as well.