CustomShiftLeft.policy

IMPORT io.shiftleft/default
IMPORT io.shiftleft/defaultdict

### These methods are approved by AppSec ###
### TAG "CHECK" METHOD - This prefix indicates that the method is anapproved validation method
### Pass the full name after -f using the below syntax
### Package name . Class name . Method name : Return type ( Argument type )
# Package name: io.shiftleft.controller
# Class name: AdminController
# Method name: isAdmin
# Return type: boolean
# Arguments: String (Expressed as java.lang.String in full form)

TAG "CHECK" METHOD -f "io.shiftleft.controller.AdminController.isAdmin:boolean(java.lang.String)"

### MORE CUSTOM APP POLICIES ###

TAG "CHECK" METHOD -f "javax.servlet.http.HttpServletRequest.setAttribute:void(java.lang.String,java.lang.Object)"
TAG "CHECK" METHOD -f "io.shiftleft.tarpit.Insider.validate:java.lang.String(java.lang.String)" 


### CUSTOM CONCLUSION ###
#
# Use these augment what you want to communicate to your developers
# or to adjust severity

CONCLUSION xss-to-header = FLOW IO (http OR $http) -> IO (httpHeader)
WHEN CONCLUSION xss-to-header => EMIT {
     title: "XSS: HTTP data to header {{via `$paramname`}} {{in `$methodname`}}",
     category: "a7-XSS",
     description: "Data from HTTP request parameters is stored in HTTP headers. Unless the string is validated, this may result in a XSS attack.

## Customer Specific Information

I can point my devs to specific internal resources for this specific finding type xss-to-header
...or I could have adjusted the cvss score from 8.0 to something else

## Countermeasures
This vulnerability can be prevented by using input sanitization/validation techniques (e.g., whitelisting) on the HTTP data before using it inside another HTTP header.

## Additional information

**[CWE-79](https://cwe.mitre.org/data/definitions/79.html)**
**[OWASP-A7](https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A7-Cross-Site_Scripting_(XSS))**",
     score: "8.0",
     vulnerability_description: "XSS",
     owasp_link: "https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A7-Cross-Site_Scripting_(XSS)",
     link: "https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A7-Cross-Site_Scripting_(XSS)",
     cwe_link: "https://cwe.mitre.org/data/definitions/79.html"
}

CONCLUSION xss-to-html = FLOW IO (http) -> DATA (NOT encrypted AND NOT hashed AND NOT escaped AND NOT encoded) -> IO (html AND NOT session)
WHEN CONCLUSION xss-to-html => EMIT {
     title: "XSS: HTTP data to HTML {{via `$paramname`}} {{in `$methodname`}}",
     category: "a7-XSS",
     description: "Data from HTTP request parameters is used in HTML or session information. Unless the string is validated, this may result in a XSS attack.

## Internal help

I can point my devs to specific internal resources for this specific finding type xss-to-html
...or I could have adjusted the cvss score from 8.0 to something else

## Countermeasures

This vulnerability can be prevented by using input sanitization/validation techniques (e.g., whitelisting) on the HTTP data before using it inside another HTTP header.


## Additional information

**[CWE-79](https://cwe.mitre.org/data/definitions/79.html)**

**[OWASP-A7](https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A7-Cross-Site_Scripting_(XSS))**",
     score: "8.0",
     vulnerability_description: "XSS",
     owasp_link: "https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A7-Cross-Site_Scripting_(XSS)",
     link: "https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A7-Cross-Site_Scripting_(XSS)",
     cwe_link: "https://cwe.mitre.org/data/definitions/79.html"
}