Does AntiXss have method to retain some safe html tags?

Aug 3, 2013 at 8:58 PM
the code is like this,
the action:
 public ActionResult Test()
            const string strHtml = @"<p>
                                                        <b>what's your name?</b>
                                                    <div class='DetailPanel'>
                                                        my name is xiaoseg.
            ViewBag.strHtml = strHtml;
            return View();
the view:
use the GetSafeHtml() method,the Response html is this:
<p>what's your name? </p>
my name is xiaoseg.
some html tags that i think is safe,but been removed!
This result is not what I want!
so, is there any method to solve this problem?
Nov 11, 2013 at 2:13 PM
I have same problem.
Nov 14, 2013 at 5:08 PM
This problem can be resolved within the intended 4.2 design pattern.
The core change to 4.2 was addressing CVE-2012-0007, Technet MS12-007, US Cert TA12-010A, Secunia 47483 & 47516.

The Microsoft AntiXSS Library 3.X and < 4.2 allow attackers to preface an XSS attack with a CSS string which remotely disables the library. The net impacts is remote code execution, elevation of privileges, compromise of the users session, compromise of the data in the application, compromise of the end user device, bank fraud, NPI data breech. Regulatory Drivers: HIPPA, SOX, GHLBA, PCI, OWASP, MITRE, NIST, SANS, FERC, NERC, FISMA with advisories from IBM, WatchFire, Microsoft

So..., If we were were writing up a design remediation requirements doc it would be advised to angled to estimate and get LOB approved budget to engineer fix and test , not apply a quick MS code patch.

Where you have sent code into production without implemented changes to correct your system, after Jan 10th, 2012 you may have missed or misread the severity and the necessary least level of efforts which should be considered as a remediation requirement.

Solution Requirements
  • Where possible, use the positive security model control implementing GetSafeHtml over encoding user space origin data according to its context.
Actions required
Design / Fix / Test code with new requirements according to the available design pattern to mitigate the high, critical and likely (imminent) remotely exploitable issue affecting internal and external facing apps.

In the short term as a temporary brief mitigation, consider additional applicable Web Application Firewall WAF rules to remediate the particular CSS bypass exploit realizing that it is not a substitute for following the vendors intended best practice design pattern.

On a side note: The Microsoft's intended best practice design pattern is identical to what Java programmers have needed to do for over a decade to fix the same issue. Exactly the same issue scope, impact and same remediation.

Detailed Design requirements
  • Where use GetSafeHtml is not appropriate build the HTML string using a combination of whitelist validated, static trusted and user space data origin data encoded according to its context.
  • Build the dynamic HTML to render by encoding data with a user space data origin according to its context; HTML, attribute, javascript, URL
Functional security validation
  • Ensure no trust boundary violations exist where trusted static output (which does not need encoding) is mixed in the rendered HTML with data with a user space data origin. User space data not encoded according to its context should fail the functional validation.
Hope this helps to illuminate the terrain in which you find yourself.

Henry (Not affiliated with Microsoft or Codeplex or subsidiary)

Legal disclaimer
Poster (that's me) intends and reader consents that information, recommendation and what may be perceive as "advise" use is "As Is" with no suitability as a requirement for or remediation of any particular security or other purpose the reader may intend. Take what you can and leave the rest.