JSchade052405 (Community Member) asked a question.

CWE 80 Basic XSS issue for reading byte

      else if (fileBytes != null && fileBytes.Length > 0)

      {

        string htmlContent = System.Web.HttpUtility.HtmlDecode((System.Web.HttpUtility.HtmlEncode(System.Text.Encoding.UTF8.GetString(fileBytes, 0, fileBytes.Length))));

        htmlContent = AntiXssEncoder.HtmlEncode(htmlContent, true);

        fileBytes = Encoding.UTF8.GetBytes(htmlContent);

 

        Response.Clear();

        MemoryStream ms = new MemoryStream(fileBytes);

        Response.ContentType = "text/plain";

        Response.AddHeader("content-disposition", "attachment;filename=" + fileName);

        Response.Buffer = true;

        ms.WriteTo(Response.OutputStream); //this line generates the XSS flag

        Response.End();

      }

 

I'm encoding the html string using the AntiXssEncoder class as recommended, yet this keeps throwing

 


VCode likes this.
  • Seb! (Veracode)

    Hi @JSchade052405 (Community Member)​ 

     

    From your code sample it looks like this class is some sort of proxy to a file store which allows a user to download a file. Is this just a flat file? Will the file ever be opened in a browser?

     

    I would have expected htmlContent being passed through the AntiXssEncoder would have remediated this flaw. I don't have enough details do say why the scanner is flagging this for XSS, there maybe some more details in the flaw description or the data path which may suggest where the problem lies? It may also be worth tracing the value of fileName and ensuring that is validated before being applied to the HTTP Header.

     

    We would also recommend that the header "X-Content-Type-Options" is also set on the response with the value set to "nosniff". Currently in old versions of IE, if the file being downloaded contains HTML/CSS/JS then IE may ignore the Content-Type and "sniff/guess" incorrectly, allowing this mechanism to be bypassed. Setting this header ensures that Content-Type is always honoured.

     

    Generally, as this would appear to be a flat file not intended for a browser context, I would agree with this approach. Once the X-Content-Type-Options header is set it would be worth discussing with your security team, as they way forward may be the mitigation workflow.

     

    Thanks! Seb

    Expand Post

Topics (4)

No articles found
Loading

Ask the Community

Get answers, share a use case, discuss your favorite features, or get input from the community.