2

I recently posted a question about recovery of website from XSS attacks, https://stackoverflow.com/questions/20759081/how-to-recover-a-site-after-an-xss-attack...

Doing a bit more digging online, i found that the site is vulnerable to XSS if it allows user to give input or in other words, have any sort of input box in the site (like search box, contact us form, post a feedback etc. )

Now, what i want to know is that :

  • assuming a site has got no input boxes, is it still vulnerable to XSS attack, if yes, then how?
  • apart from XSS, other hack-attacks a site can face if it hasn't got any input boxes for user

I know, its a pretty broad question, i just need some heads-up on the topic to google for!!

P.S : i posted this question on Stackoverflow and then was told that this is a better platform to ask this question, SO question link : stackoverflow.com/questions/20783204/what-hacking-risks-a-site-has-if-it-has-no-input-boxes, and its my 1st question here, so please correct me for TAGS fo this question!!

  • "input boxes" as the source of all vulnerabilities... I have never herd this before and will never hear this again. – rook Dec 26 '13 at 15:44
  • One thing everyone has seemed to miss in the answers is the fact that the web server itself can be attacked. – 에이바 Jan 10 '14 at 20:36
6

Even though a site my have no input boxes, it will still process input. Examples of these types of input are:

  • HTTP headers.
  • Cookie values.
  • Query string values.
  • POST data.

If the site displays any of these values back within an HTML page, the values should be properly encoded to prevent XSS.

For example, if a page output the values of the User-Agent headers of all visitors in HTML to list the raw details of all the browsers that have been used, a malicious attacker could set their header value to be malicious JavaScript code and then visit the page that records the headers.

There are many attacks possible, please see the OWASP Top 10 2013 for some examples, none of which require input boxes to be used.

  • Bear in mind that a XSS attack is typically only useful if the value from one user is persisted (typically to a database) and then reshown to another user. So in the user-agent example, this would be a useful attach if the user-agent was stored from malicious attacker and then redisplayed in HTML when an admin logs in causing a redirect to a rogue site while capturing their cookies (and therefore session) in the querystring. Then someone from the rogue site could visit the original site and be the admin user by taking over their session. – jamiescott Dec 28 '13 at 17:02
  • @jamiescott More accurately, a persisted XSS attack is typically only useful if the value from one user is shown to other users. Reflected XSS (where the payload is baked into the request itself) does not have this property (but requires that the attacker socially engineers the victim into visiting the URL containing the payload - e.g. by sending them a tinyurl link promising pictures of cats - rather than waiting for them to stumble upon the payload by browsing normally.) – Mark Amery Jan 19 '14 at 13:10
4

assuming a site has got no input boxes, is it still vulnerable to XSS attack, if yes, then how?

User input can still from other places rather than just input boxes (possibly causing XSS, SQL injection, site redirects and more):

  1. Querystring values
  2. Form values (just because it has no forms doesn't mean the site isn't accepting POST)
  3. Cookie values
  4. HTTP headers

apart from XSS, other hack-attacks a site can face if it hasn't got any input boxes for user

It is worth doing some reading in this area - there are so many attacks to consider. One of my favorite books is 19 Deadly Sins of Software Security

  • (just because it has no forms doesn't mean the site isn't accepting POST)....how?? – NoobEditor Dec 26 '13 at 14:28
  • 2
    A website generally accepts HTTP requests as either GET or POST. The code to handle POST can exist in the backend website regardless of whether there are any forms on the actual website. One way to think about it would be - a form on one website submits to a page on another website. – jamiescott Dec 26 '13 at 15:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.