CRV2 ClientSideCodeBrowserDefPol

Browser Defense

Examples

The following figure displays two example URIs (foo://username:[email protected]:8042/over/there/index.dtb?type=animal&name=narwhal#nose and urn:example:animal:ferret:nose) and their component parts. (The examples are derived from RFC 3986 — STD 66, chapter 3).

  foo://username:[email protected]:8042/over/there/index.dtb?type=animal&name=narwhal#nose
  \_/   \_______________/ \_________/ \__/            \___/ \_/ \______________________/ \__/
   |           |               |       |                |    |            |                |
   |       userinfo         hostname  port              |    |          query          fragment
   |    \________________________________/\_____________|____|/ \__/        \__/
   |                    |                          |    |    |    |          |
   |                    |                          |    |    |    |          |
scheme              authority                    path   |    |    interpretable as keys
 name   \_______________________________________________|____|/       \____/     \_____/
   |                         |                          |    |          |           |
   |                 hierarchical part                  |    |    interpretable as values
   |                                                    |    |
   |            path               interpretable as filename |
   |   ___________|____________                              |
  / \ /                        \                             |
  urn:example:animal:ferret:nose               interpretable as extension

                path
         _________|________
 scheme /                  \
  name  userinfo  hostname       query
  _|__   ___|__   ____|____   _____|_____
 /    \ /      \ /         \ /           \
 mailto:[email protected]?subject=Topic

S

1. Scheme/protocol name
2. Indicator of a hierarchical URL (constant)_
3. Credentials to access the resource (optional)
4. Server to retrieve the data from
5. Port number to connect to (optional)
6. Hierarchical Unix path to a resource
7. “Query string” parameters (optional)
8. “Fragment identifier” (optional)

If application allows user-supplied data in the URL then the code reviewer needs to make sure the path, query or Fragment Id Code data is validated.

Make sure user-supplied scheme name or authority section has good input validation. This is a major code injection and phishing risk. Only permit prefixes needed by the application. Do not use blacklisting. Code reviewer should make sure only whitelisting is used for validation.

Make sure authority section should only contain alphanumerics, “-“, and “.” And be followed by “/”, “?”,”#”. The risk here an IDN homograph attack.

Code reviewer needs to make sure the programmer is not assuming default behavior because the programmers browser properly escapes a particular character or browser standard says the character will be escaped properly before allowing any URL-derived values are put inside a database query or the URL is echoed back to the user.