2

My website is an information only website and all the information on it is available to all those who visit the website.

There is no sensitive data. And we do not store any user submitted data nor there are user accounts \login. There are no forms for the same and the the ones available are mostly drop-down values with an exception of a few.

Considering all this, how important is security on my website and what are the attacks that I need to be careful about?

Most of them in the report are under the below category. I believe all we need to do here is to make sure all the forms do not accept contents with html tags?

Reflected Cross-site scripting (XSS)

Any help?

  • 1
    You ask a separate question for each bullet and encourage more answers of the same type. It does not seem suitable for the StackExchange format. – techraf Jul 29 '16 at 0:15
  • @techraf I shall do the same and edit the question appropriately. Thanks for the suggestion – Chillax Jul 29 '16 at 10:33
2

Damage of XSS on Information-only Website

Yes, XSS is an issue even on an information-only website with no user accounts or personal information.

What can happen:

  • Phishing: It's true, an attacker cannot try to get information that is specific to your website - such as login credentials - as they do not exist. But - depending on your website - they can still exploit the trust a user has in your site to gather information from the user.
  • Defacement: An attacker can change the look of your website any way they want. They can add false information, they can add inappropriate images, and so on. Depending on your website, this may have rather large ramifications.
  • Open Redirect: May be used in phishing attacks.
  • Drive-By-Downloads: An attacker may exploit issues in the browser leading to drive-by-downloads, or may add links to harmful files to your website.

As you can see, the damage results from two things:

  • A user has trust in your website, which may be exploited to harm the user (but not your website).
  • XSS can be used to cause harm to the image of your website, and thus to the image of your organization.

You should also keep in mind that:

  1. Your website may change, and may later include a user area or an administration area.
  2. There may be other applications on the same domain, which do have such areas, which may thus be exploited via XSS in this application.

Defending against XSS

I believe all we need to do here is to make sure all the forms do not accept contents with html tags?

Not really. For proper defenses against XSS see OWASP.

Not accepting HTML tags may not be enough, think <img src="[USER_INPUT]">.

Other Risks to Information-only websites

Considering all this, how important is security on my website and what are the attacks that I need to be careful about?

Security is still relevant, even for information-only websites.

You probably do not want an attacker gaining complete control of your server, so at the very least, these are issues you should be concerned about:

  • Injection: SQL Injection may be used to DOS your server, and depending on the specifics, an attacker may gain control of your server with it. OS command injection is obviously also relevant, you really don't want an attacker to have complete control of your server.
  • Insecure File Uploads: You definitely do not want people to upload any file they want.
  • Other vulnerabilities that attack the server may also be relevant, such as XXE, Object Injection, DOS in general,

Any vulnerabilities that are linked to authentication or authorization - such as broken authentication, insecure direct object reference, etc - are probably not relevant to you - at least for now.

  • Thanks. Very helpful. We are taking care of SQL injection (named parameters). Also can you tell us how HTTP verb tampering (get to post) might affect our site? – Chillax Jul 29 '16 at 14:46
  • @Chillax that would probably be a good separate question. Of the top of my head, I can't think of a problem with GET to POST (the other way around wouldn't be good though, and that your application does allow some interchangeability may be a sign that that may also be possible, or at least that developers do not see a real distinction between GET and POST, but treat them as interchangeable). – tim Jul 29 '16 at 15:10

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.