1

I have submitted a pentest report in which I have reported XSS at a few locations in an application. The management agreed to the risk. They have planned to remediate the issue in the next thirty days. However, they asked what needs to be done from their side in those thirty days so as to minimize the risk while they resolve the issue. Please note that the application is a highly sensitive asset available over office network only.

one
  • 1,781
  • 3
  • 18
  • 45

2 Answers2

1

This is primarily a business decision. There are two extremes:

  • Accept the risk - just carry on and hope no hackers exploit this.
  • Turn off the application - no chance to it being hacked if it's turned off.

In practice, the risk of XSS on an internal network is pretty low. If external attackers are on the network, they can probably do worse things. Malicious insiders tend to abuse legitimate access rather than engage in hacking. On the other hand, turning off the application would probably have a major business impact. So most businesses would accept this risk.

There are technical measures that can mitigate the risk. For example:

  • Install a WAF - although installing and tuning this will probably take more than 30 days.
  • Change user behaviour - Users need close all other browser Windows (and tabs) while using the internal application, and logout when they are finished. This makes XSS in the internal app non-exploitable - although it's a pain for users.

Ultimately though, your business agreeing to fix the issues within 30 days is a pretty good response. A lot of businesses take security flaws in internal apps far less seriously.

paj28
  • 32,736
  • 8
  • 92
  • 130
0

Ask their security experts or back-end developers to make a plugin like HTMLCutter Plugin, so that it just filters and sanitises all the input which is given by the user before processing their inputs. Alternate steps that can be taken are

1) You Need a Security Encoding Library => http://wpl.codeplex.com/ - Microsoft's encoding library

2) HTML Escape Before Inserting Untrusted Data into HTML Element Content

    Search for ESAPI Reference Implementation on code.google.com

    Command String safe = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) );

3)Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes

String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) );

4) JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values

String safe = ESAPI.encoder().encodeForJavaScript( request.getParameter( "input" ) );

5) CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values

String safe = ESAPI.encoder().encodeForCSS( request.getParameter( "input" ) );

6) URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values

String safe = ESAPI.encoder().encodeForURL( request.getParameter( "input" ) );

7) Sanitize HTML Markup with a Library Designed for the Job

You can find code on github for HTMLSanitizer, Ruby on Rails Sanitizer etc..

8) Prevent DOM-based XSS

Additional Tips:

I) Use HTTPOnly cookie flag

II) Implement Content Security Policy

III) Use an Auto-Escaping Template System

IV) Use the X-XSS-Protection Response Header

Hope this helps to solve the issue.

Rewanth Tammana
  • 111
  • 3