Application Security Report
Back to summary report
Company: Example, Inc.
C
Average
Scan Date: October 05, 2017
Description: The contents of each web application are collected from various internet-wide scanners and are analyzed for application level weaknesses i.e. Cross Site Request Forgery, Cross Content Mixing, Plain Text Transmission of Sensitive Information etc. The results are also correlated with MITRE CWE database to detect the severity level of each finding.
This report category has 7% effect on total scan score.

Application Security Results Overview (Top 50)

# Asset # of Finding(s)
Passed Info Warning Failed
204117 http://ophat.extportal.example.com 11 8 10 3
204133 http://immpost.portal.example.com 11 8 10 3
204132 https://www.portal.wcb.example.com 11 8 12 2
204466 https://ftp.example.org 12 8 11 2
204468 https://webmail.example.org 12 8 11 2
204472 https://mail.example.org 12 8 11 2
204052 https://pebbtest.example.com 14 8 9 2
204093 https://myoebb.oha.example.com 14 8 9 2
204102 https://wic-service.portal.example.com 14 8 9 2
204116 https://pebb.benefits.oha.example.com 14 8 9 2
204060 https://one.example.com 17 8 5 2
204088 https://immpost-test.portal.example.com 12 8 11 1
204134 https://immpost.portal.example.com 12 8 11 1
204331 https://www.ohsionline-example.org 12 8 11 1
204332 https://ohsionline-example.org 12 8 11 1
204351 https://www.ohsionline-example.org 12 8 11 1
204353 https://ohsionline-example.org 12 8 11 1
204367 https://www.ohsionline-example.org 12 8 11 1
204372 https://ohsionline-example.org 12 8 11 1
204386 https://ohsionline-lrapp.org 12 8 11 1
204388 https://www.ohsionline-lrapp.org 12 8 11 1
204470 https://www.example.org 12 8 11 1
204477 https://example.org 12 8 11 1
204118 https://ophat.extportal.example.com 13 8 10 1
204121 http://omb.example.com 13 8 10 1
204129 https://appellate-extcourts.example.com 13 8 10 1
204144 https://epht.example.com 13 8 10 1
204405 https://tillamookfc.com 13 8 10 1
204071 http://sexoffenders.example.com 14 8 9 1
204113 https://call.uc.example.com 15 8 9 1
204120 https://tspc.example.com 15 8 9 1
204143 http://epht.example.com 14 8 9 1
204176 https://www.yourwater.example.com 15 8 9 1
204087 https://icaa.oha.example.com 14 8 9 1
204146 https://racedo.ets.example.com 16 8 8 1
204190 https://mail.doc.example.com 16 7 8 1
204448 https://exampleboa.com 16 7 8 1
204104 https://raohix.ets.example.com 17 8 7 1
204421 https://gosgmp.org 17 8 7 1
204072 https://ojdvsp.courts.example.com 19 8 4 1
204085 https://opdscore.courts.example.com 19 8 4 1
204097 https://licensesonline.dcbs.example.com 13 8 11 0
204111 http://teachin.example.com 13 8 11 0
204159 https://ojdvideomea.courts.example.com 13 7 11 0
204056 https://billing.ets.example.com 14 8 10 0
204069 https://rps.licenseeservices.extportal.example.com 14 8 10 0
204078 http://extportal.example.com 14 8 10 0
204090 http://editors.extportal.example.com 14 8 10 0
204099 https://wrdemail-archive.example.com 14 8 10 0
204105 http://hrlb.example.com 14 8 10 0

Application Security Results for http://ophat.extportal.example.com (13)

ID Finding Status
2532673

APPSEC Cleartext Transmission of Sensitive Information (CWE-319)

Many communication channels can be sniffed by attackers during data transmission. For example, network traffic can often be sniffed by any attacker who has access to a network interface. This significantly lowers the difficulty of exploitation by attackers.

Form Action: /Account/LogOn
Input ID: Password

Mitigation

Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols. Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

References

Failed
2532674

APPSEC Missing encryption of sensitive data or critical information before storage or transmission (CWE-311)

The lack of proper data encryption passes up the guarantees of confidentiality, integrity, and accountability that properly implemented encryption conveys. If the application does not use a secure channel, such as SSL, to exchange sensitive information, it is possible for an attacker with access to the network traffic to sniff packets from the connection and uncover the data. This attack is not technically difficult, but does require physical access to some portion of the network over which the sensitive data travels. This access is usually somewhere near where the user is connected to the network (such as a colleague on the company network) but can be anywhere along the path from the user to the end server

Form Action: /Account/LogOn
Input ID: Password

Mitigation

Clearly specify which data or resources are valuable enough that they should be protected by encryption. Require that any transmission or storage of this data/resource should use well-vetted encryption algorithms. Using threat modeling or other techniques, assume that the data can be compromised through a separate vulnerability or weakness, and determine where encryption will be most effective. Ensure that data that should be private is not being inadvertently exposed using weaknesses such as insecure permissions (CWE-732). [R.311.1]

References

Failed
2532677

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /Account/LogOn
 Input ID: UserName
 Input ID: Password

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2532672

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /Account/LogOn
Input ID: Password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2532650

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2532657

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2532649

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2532651

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2532652

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2532655

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2532656

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2532658

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2532659

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning


Application Security Results for http://immpost.portal.example.com (13)

ID Finding Status
2533186

APPSEC Cleartext Transmission of Sensitive Information (CWE-319)

Many communication channels can be sniffed by attackers during data transmission. For example, network traffic can often be sniffed by any attacker who has access to a network interface. This significantly lowers the difficulty of exploitation by attackers.

Form Action: ./SignIn.aspx?ReturnUrl=%2f
Form Name: aspnetForm
Input ID: Password

Mitigation

Configure servers to use encrypted channels for communication, which may include SSL or other secure protocols. Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

References

Failed
2533187

APPSEC Missing encryption of sensitive data or critical information before storage or transmission (CWE-311)

The lack of proper data encryption passes up the guarantees of confidentiality, integrity, and accountability that properly implemented encryption conveys. If the application does not use a secure channel, such as SSL, to exchange sensitive information, it is possible for an attacker with access to the network traffic to sniff packets from the connection and uncover the data. This attack is not technically difficult, but does require physical access to some portion of the network over which the sensitive data travels. This access is usually somewhere near where the user is connected to the network (such as a colleague on the company network) but can be anywhere along the path from the user to the end server

Form Action: ./SignIn.aspx?ReturnUrl=%2f
Form Name: aspnetForm
Input ID: Password

Mitigation

Clearly specify which data or resources are valuable enough that they should be protected by encryption. Require that any transmission or storage of this data/resource should use well-vetted encryption algorithms. Using threat modeling or other techniques, assume that the data can be compromised through a separate vulnerability or weakness, and determine where encryption will be most effective. Ensure that data that should be private is not being inadvertently exposed using weaknesses such as insecure permissions (CWE-732). [R.311.1]

References

Failed
2533190

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: ./SignIn.aspx?ReturnUrl=%2f
Form Name: aspnetForm
 Input ID: __LASTFOCUS
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: __VIEWSTATE
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: UserName
 Input ID: Password
 Input ID: LoginButton

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2533185

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: ./SignIn.aspx?ReturnUrl=%2f
Form Name: aspnetForm
Input ID: Password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2533166

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2533172

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2533162

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2533163

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2533164

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2533165

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2533167

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2533168

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2533169

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning


Application Security Results for https://www.portal.wcb.example.com (14)

ID Finding Status
2533142

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2533150

APPSEC Information Exposure Through Comments (CWE-615)

An attacker who finds these comments can map the application's structure and files, expose hidden parts of the site, and study the fragments of code to reverse engineer the application, which may help develop further attacks against the site.
Sensitive comment found: 
<!-- Do not remove this anchor. It's required for Macintosh compatibility -->

Mitigation

Remove comments which have sensitive information about the design/implementation of the application. Some of the comments may be exposed to the user and affect the security posture of the application.

References

Failed
2533155

APPSEC Cookie without HttpOnly flag set (CWE-87)

If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie's value via an injected script.

Cookie ID:
Cookie Name: ION_BYPASS_LIST
HTTPOnly: False
Path: /
Secure: False

Cookie ID:
Cookie Name: ION_DISMISSED_MESSAGES
HTTPOnly: False
Path: /
Secure: False

Mitigation

There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.

References

Warning
2533156

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID:
Cookie Name: ION_BYPASS_LIST
HTTPOnly: False
Path: /
Secure: False

Cookie ID: 4051103
Cookie Name: CFID
Expires: Sat 28-Sep-2047 13:02:42 GMT
HTTPOnly: True
Path: /
Secure: False

Cookie ID: 3f26c3bd24178175-3E067CF4-9ABF-5652-CD64DCC036E75F25
Cookie Name: CFTOKEN
Expires: Sat 28-Sep-2047 13:02:42 GMT
HTTPOnly: True
Path: /
Secure: False

Cookie ID: 4051104
Cookie Name: CFID
Expires: Sat 28-Sep-2047 13:02:42 GMT
HTTPOnly: True
Path: /
Secure: False

Cookie ID: 256e8ba11c81c9b0-3E067D97-BB05-5A6D-E4BEBFBFA118723B
Cookie Name: CFTOKEN
Expires: Sat 28-Sep-2047 13:02:42 GMT
HTTPOnly: True
Path: /
Secure: False

Domain: .cbs.state.or.us
Cookie ID:
Cookie Name: _U1
Expires: 0
HTTPOnly: True
Path: /
Secure: False

Domain: .cbs.state.or.us
Cookie ID:
Cookie Name: _U2
Expires: 0
HTTPOnly: True
Path: /
Secure: False

Cookie ID:
Cookie Name: ION_DISMISSED_MESSAGES
HTTPOnly: False
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2533128

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2533129

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2533127

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2533131

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2533132

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2533134

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2533136

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2533137

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2533138

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2533139

APPSEC Http Security Header Cache-control (CWE-524)

Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Cache-control: no-store"
Cache-control header not found

Mitigation

Do not store unnecessarily sensitive information in the cache.

References

Warning


Application Security Results for https://ftp.example.org (13)

ID Finding Status
2538384

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2538400

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /default.aspx
Form ID: htmlForm
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: holderMainBody_tbxEmail
 Input ID: holderMainBody_tbxPassword_password
 Input ID: holderMainBody_btnLogin
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: __VIEWSTATE

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2538395

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /default.aspx
Form ID: htmlForm
Input ID: holderMainBody_tbxPassword_password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2538398

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: zpjbe3hdcoq3o0kok1nqgv5t
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2538374

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.0

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2538381

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2538371

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2538372

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2538373

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2538375

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2538376

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2538378

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2538380

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning


Application Security Results for https://webmail.example.org (13)

ID Finding Status
2538449

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2538465

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /default.aspx
Form ID: htmlForm
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: holderMainBody_tbxEmail
 Input ID: holderMainBody_tbxPassword_password
 Input ID: holderMainBody_btnLogin
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: __VIEWSTATE

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2538460

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /default.aspx
Form ID: htmlForm
Input ID: holderMainBody_tbxPassword_password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2538463

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: eabfyiyj3zar23w1iy4a4b1o
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2538443

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2538446

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.0

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2538434

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2538435

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2538436

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2538437

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2538441

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2538442

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2538445

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning


Application Security Results for https://mail.example.org (13)

ID Finding Status
2538515

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2538531

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /default.aspx
Form ID: htmlForm
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: holderMainBody_tbxEmail
 Input ID: holderMainBody_tbxPassword_password
 Input ID: holderMainBody_btnLogin
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: __VIEWSTATE

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2538526

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /default.aspx
Form ID: htmlForm
Input ID: holderMainBody_tbxPassword_password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2538529

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: 4e44bzprzxd3y2ngzvngn4v5
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2538502

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.0

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2538505

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2538500

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2538504

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2538506

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2538507

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2538508

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2538511

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2538512

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning


Application Security Results for https://pebbtest.example.com (11)

ID Finding Status
2530802

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2530818

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: !pb.main
Form Name: bms
 Input Name: pn_user_id
 Input Name: ps_msg_flag
 Input Name: ps_mesbms
 Input Name: pn_menu_id
 Input Name: pn_menu_level
 Input Name: pn_auth_id
 Input Name: ps_user_name
 Input Name: pn_lock_timeout
 Input Name: ps_proc_name
 Input Name: ps_browser_name
 Input Name: ps_platform_name
 Input Name: ps_member_path
 Input Name: ps_admin_module_access

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2530794

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2530787

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2530789

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2530790

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2530792

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2530795

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2530796

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2530798

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2530799

APPSEC Http Security Header Cache-control (CWE-524)

Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Cache-control: no-store"
Cache-control header not found

Mitigation

Do not store unnecessarily sensitive information in the cache.

References

Warning


Application Security Results for https://myoebb.oha.example.com (11)

ID Finding Status
2531890

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2531906

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: !pb.main
Form Name: bms
 Input Name: pn_user_id
 Input Name: ps_msg_flag
 Input Name: ps_mesbms
 Input Name: pn_menu_id
 Input Name: pn_auth_id
 Input Name: ps_user_name
 Input Name: pn_med_covopttyp_id_for_death
 Input Name: pn_dnt_covopttyp_id_for_death
 Input Name: pn_vsn_covopttyp_id_for_death
 Input Name: ps_proc_name
 Input Name: ps_browser_name
 Input Name: ps_browser_name_app
 Input Name: ps_data_os_app
 Input Name: ps_platform_name
 Input Name: ps_member_path
 Input Name: pn_global_qsc_id
 Input Name: pn_mbr_qsc_req_id
 Input Name: pn_maint_id
 Input Name: ps_last_page

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2531884

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2531875

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2531876

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2531877

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2531878

APPSEC Http Security Header Cache-control (CWE-524)

Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Cache-control: no-store"
Cache-control header not found

Mitigation

Do not store unnecessarily sensitive information in the cache.

References

Warning
2531882

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2531883

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2531885

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2531886

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning


Application Security Results for https://wic-service.portal.example.com (11)

ID Finding Status
2532179

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2532191

APPSEC HTTPS website includes references from insecure (HTTP) resources (CWE-807)

Mixed content includes resources that can greatly change the behavior of a website, such as JavaScript, CSS, fonts, and iframes. Browsers may refuse to load active mixed content, which often results in affected pages being completely unstyled or broken. Browsers treat these very aggressively because of the consequences if they were compromised. For example, a single compromised Javascript file compromises the entire website, regardless of how other resources are loaded.

Url: http://www.example.com/OHA/Style%20Library/Images/oha-logo-white.svg
Tag: img

Mitigation

Enable https for your website, but don’t force a redirect. Continue to present the http version as the canonical URL to search engines. Identify the most obvious and widespread pieces of mixed content by loading your website in a browser over https and observing breakages. Chrome, Opera, and Firefox will log any mixed content warnings to the console, which should point out necessary site-wide changes. Use these to secure your resource links. After fixing them, tackle the long tail by scanning your code and crawling your website. Finally, force the redirect to HTTPS, turn on HSTS, and tell search engines that your new URL starts with https.

References

Failed
2532193

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: -3kgAdlTLwG2hHiqfWswrIyM8RH8SiHy8S7HzJb64JBixQ9RHs0jTu4EAh3UhtPd7Z1VUrV1Pj7MxLEeEHbL9gbw4s-0w7Wg81XgId94a2E1
Cookie Name: __RequestVerificationToken
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2532173

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2532176

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2532164

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2532165

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2532168

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2532171

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2532172

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2532174

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning


Application Security Results for https://pebb.benefits.oha.example.com (11)

ID Finding Status
2532629

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2532645

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: !pb.main
Form Name: bms
 Input Name: pn_user_id
 Input Name: ps_msg_flag
 Input Name: ps_mesbms
 Input Name: pn_menu_id
 Input Name: pn_menu_level
 Input Name: pn_auth_id
 Input Name: ps_user_name
 Input Name: pn_lock_timeout
 Input Name: ps_proc_name
 Input Name: ps_browser_name
 Input Name: ps_platform_name
 Input Name: ps_member_path
 Input Name: ps_admin_module_access

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2532618

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2532614

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2532615

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2532616

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2532620

APPSEC Http Security Header Cache-control (CWE-524)

Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Cache-control: no-store"
Cache-control header not found

Mitigation

Do not store unnecessarily sensitive information in the cache.

References

Warning
2532621

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2532624

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2532625

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2532626

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning


Application Security Results for https://one.example.com (7)

ID Finding Status
2530938

APPSEC Information Exposure Through Comments (CWE-615)

An attacker who finds these comments can map the application's structure and files, expose hidden parts of the site, and study the fragments of code to reverse engineer the application, which may help develop further attacks against the site.
Sensitive comment found: 
/* Remove the default focus of the buttons in the JQuery pop up.*/

Mitigation

Remove comments which have sensitive information about the design/implementation of the application. Some of the comments may be exposed to the user and affect the security posture of the application.

References

Failed
2530945

APPSEC Cross-Site Request Forgery (CSRF) (CWE-352)

Cross-site request forgery (CSRF) vulnerabilities may arise when applications rely solely on HTTP cookies to identify the user that has issued a particular request. Because browsers automatically add cookies to requests regardless of their origin, it may be possible for an attacker to create a malicious web site that forges a cross-domain request to the vulnerable application.

Form Action: /PreScreening/LetsGetStarted
Form ID: hbeHomePageForm
 Input ID: StartingRole
 Input ID: btnStartHere
 Input ID: btnApplyNow
 Input Name: ProcessOverview

Mitigation

The most effective way to protect against CSRF vulnerabilities is to include within relevant requests an additional token that is not transmitted in a cookie: for example, a parameter in a hidden form field. This additional token should contain sufficient entropy, and be generated using a cryptographic random number generator, such that it is not feasible for an attacker to determine or predict the value of any token that was issued to another user. The token should be associated with the user's session, and the application should validate that the correct token is received before performing any action resulting from the request.

References

Failed
2530926

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2530916

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2530917

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2530922

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2530928

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning


Application Security Results for https://immpost-test.portal.example.com (12)

ID Finding Status
2531745

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: ./SignIn.aspx?ReturnUrl=%2f
Form Name: aspnetForm
 Input ID: __LASTFOCUS
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: __VIEWSTATE
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: UserName
 Input ID: Password
 Input ID: LoginButton

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2531740

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: ./SignIn.aspx?ReturnUrl=%2f
Form Name: aspnetForm
Input ID: Password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2531743

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID:
Cookie Name: POST
Expires: Tue 12-Oct-1999 07:00:00 GMT
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2531721

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2531723

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2531715

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2531717

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2531718

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2531722

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2531724

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2531726

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2531727

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning


Application Security Results for https://immpost.portal.example.com (12)

ID Finding Status
2533222

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: ./SignIn.aspx?ReturnUrl=%2f
Form Name: aspnetForm
 Input ID: __LASTFOCUS
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: __VIEWSTATE
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: UserName
 Input ID: Password
 Input ID: LoginButton

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2533217

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: ./SignIn.aspx?ReturnUrl=%2f
Form Name: aspnetForm
Input ID: Password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2533220

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID:
Cookie Name: POST
Expires: Tue 12-Oct-1999 07:00:00 GMT
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2533198

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2533204

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2533194

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2533195

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2533196

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2533197

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2533199

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2533200

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2533201

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning


Application Security Results for https://www.ohsionline-example.org (12)

ID Finding Status
2536566

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /default.aspx
Form ID: htmlForm
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: holderMainBody_tbxEmail
 Input ID: holderMainBody_tbxPassword_password
 Input ID: holderMainBody_btnLogin
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: __VIEWSTATE

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2536561

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /default.aspx
Form ID: htmlForm
Input ID: holderMainBody_tbxPassword_password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2536564

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: jd4mkldeuj5exebqkwch3z4l
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2536543

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2536547

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.0

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2536536

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2536537

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2536538

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2536540

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2536542

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2536546

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2536548

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning


Application Security Results for https://ohsionline-example.org (12)

ID Finding Status
2536598

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /default.aspx
Form ID: htmlForm
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: holderMainBody_tbxEmail
 Input ID: holderMainBody_tbxPassword_password
 Input ID: holderMainBody_btnLogin
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: __VIEWSTATE

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2536593

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /default.aspx
Form ID: htmlForm
Input ID: holderMainBody_tbxPassword_password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2536596

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: jmrek0cxzor4dmjg25sexyse
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2536575

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.0

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2536580

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2536568

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2536570

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2536571

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2536573

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2536574

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2536576

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2536578

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning


Application Security Results for https://www.ohsionline-example.org (12)

ID Finding Status
2536823

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /default.aspx
Form ID: htmlForm
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: holderMainBody_tbxEmail
 Input ID: holderMainBody_tbxPassword_password
 Input ID: holderMainBody_btnLogin
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: __VIEWSTATE

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2536818

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /default.aspx
Form ID: htmlForm
Input ID: holderMainBody_tbxPassword_password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2536821

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: wndel3dw1gd3jrpvkxxrgdch
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2536793

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2536803

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.0

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2536796

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2536797

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2536798

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2536799

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2536801

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2536804

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2536805

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning


Application Security Results for https://ohsionline-example.org (12)

ID Finding Status
2536876

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /default.aspx
Form ID: htmlForm
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: holderMainBody_tbxEmail
 Input ID: holderMainBody_tbxPassword_password
 Input ID: holderMainBody_btnLogin
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: __VIEWSTATE

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2536871

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /default.aspx
Form ID: htmlForm
Input ID: holderMainBody_tbxPassword_password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2536874

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: 4qe2e21tcok4zsvyctklqsuh
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2536847

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.0

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2536852

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2536846

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2536850

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2536851

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2536854

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2536855

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2536857

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2536858

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning


Application Security Results for https://www.ohsionline-example.org (12)

ID Finding Status
2537047

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /default.aspx
Form ID: htmlForm
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: holderMainBody_tbxEmail
 Input ID: holderMainBody_tbxPassword_password
 Input ID: holderMainBody_btnLogin
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: __VIEWSTATE

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2537042

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /default.aspx
Form ID: htmlForm
Input ID: holderMainBody_tbxPassword_password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2537045

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: xg4jih4pvhv5uu4avdfcbuh1
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2537017

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2537029

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.0

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2537018

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2537020

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2537021

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2537022

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2537023

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2537025

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2537028

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning


Application Security Results for https://ohsionline-example.org (12)

ID Finding Status
2537157

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /default.aspx
Form ID: htmlForm
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: holderMainBody_tbxEmail
 Input ID: holderMainBody_tbxPassword_password
 Input ID: holderMainBody_btnLogin
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: __VIEWSTATE

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2537152

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /default.aspx
Form ID: htmlForm
Input ID: holderMainBody_tbxPassword_password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2537155

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: vyalcui12xcjijzogrdeb0gk
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2537132

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2537135

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.0

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2537127

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2537128

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2537129

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2537130

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2537131

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2537136

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2537137

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning


Application Security Results for https://ohsionline-lrapp.org (12)

ID Finding Status
2537346

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /default.aspx
Form ID: htmlForm
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: holderMainBody_tbxEmail
 Input ID: holderMainBody_tbxPassword_password
 Input ID: holderMainBody_btnLogin
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: __VIEWSTATE

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2537341

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /default.aspx
Form ID: htmlForm
Input ID: holderMainBody_tbxPassword_password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2537344

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: x5vex5scoqmvlkgzkwmwsmgs
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2537322

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2537326

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.0

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2537316

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2537317

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2537318

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2537319

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2537321

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2537324

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2537325

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning


Application Security Results for https://www.ohsionline-lrapp.org (12)

ID Finding Status
2537410

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /default.aspx
Form ID: htmlForm
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: holderMainBody_tbxEmail
 Input ID: holderMainBody_tbxPassword_password
 Input ID: holderMainBody_btnLogin
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: __VIEWSTATE

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2537405

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /default.aspx
Form ID: htmlForm
Input ID: holderMainBody_tbxPassword_password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2537408

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: gdk2pkouyrsp45cgh5syjar4
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2537385

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.0

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2537392

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2537382

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2537384

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2537386

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2537387

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2537388

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2537390

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2537391

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning


Application Security Results for https://www.example.org (12)

ID Finding Status
2538497

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /default.aspx
Form ID: htmlForm
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: holderMainBody_tbxEmail
 Input ID: holderMainBody_tbxPassword_password
 Input ID: holderMainBody_btnLogin
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: __VIEWSTATE

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2538492

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /default.aspx
Form ID: htmlForm
Input ID: holderMainBody_tbxPassword_password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2538495

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: r0tjiasnwilk2hwsjwthydvr
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2538471

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2538475

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.0

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2538467

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2538468

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2538469

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2538472

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2538476

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2538477

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2538479

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning


Application Security Results for https://example.org (12)

ID Finding Status
2538607

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /default.aspx
Form ID: htmlForm
 Input ID: __EVENTTARGET
 Input ID: __EVENTARGUMENT
 Input ID: holderMainBody_tbxEmail
 Input ID: holderMainBody_tbxPassword_password
 Input ID: holderMainBody_btnLogin
 Input ID: __VIEWSTATEGENERATOR
 Input ID: __EVENTVALIDATION
 Input ID: __VIEWSTATE

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2538602

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /default.aspx
Form ID: htmlForm
Input ID: holderMainBody_tbxPassword_password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2538605

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: pxgxkujnf5x43rlg3fjttc3s
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2538578

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.0

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2538584

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2538577

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2538579

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2538580

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2538582

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2538583

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2538587

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2538588

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning


Application Security Results for https://ophat.extportal.example.com (11)

ID Finding Status
2532709

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /Account/LogOn
 Input ID: UserName
 Input ID: Password

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2532704

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /Account/LogOn
Input ID: Password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2532682

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2532689

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2532681

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2532683

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2532684

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2532687

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2532688

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2532690

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2532691

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning


Application Security Results for http://omb.example.com (11)

ID Finding Status
2532798

APPSEC Information Exposure Through Comments (CWE-615)

An attacker who finds these comments can map the application's structure and files, expose hidden parts of the site, and study the fragments of code to reverse engineer the application, which may help develop further attacks against the site.
Sensitive comment found: 
// Remove if the IM pressence icons are needed in SharePoint
<!-- NOTE: s4-nosetwidth is used when you are setting a fixed page width in css, remove for 100% -->
<!-- Remove this credit if you want, but if you leave it in I will appreciate it! -->
/* fix scrolling on list pages */

Mitigation

Remove comments which have sensitive information about the design/implementation of the application. Some of the comments may be exposed to the user and affect the security posture of the application.

References

Failed
2532804

APPSEC Cookie without HttpOnly flag set (CWE-87)

If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie's value via an injected script.

Cookie ID: rd1530o00000000000000000000ffffac1f217bo80
Cookie Name: BIGipServer~Example~OR-prd-moss.pool
HTTPOnly: False
Path: /
Secure: False

Mitigation

There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.

References

Warning
2532778

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2532783

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2532776

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2532777

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2532780

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2532781

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2532785

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2532786

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2532787

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning


Application Security Results for https://appellate-extcourts.example.com (11)

ID Finding Status
2533062

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: /login.do;jsessionid=3E76F198692CE6B11FB540E52B3CC370
Form Name: loginForm
 Input Name: forwardURI
 Input Name: username
 Input Name: password
 Input Name: submitValue

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2533057

APPSEC Password or sensitive form field with autocomplete attribute or information exposure through browser caching (CWE-525)

For each web page, the application should have an appropriate caching policy specifying the extent to which the page and its form fields should be cached. Browsers often store information in a client-side cache, which can leave behind sensitive information for other users to find and exploit, such as passwords or credit card numbers. The locations at most risk include public terminals, such as those in libraries and Internet cafes.

Form Action: /login.do;jsessionid=3E76F198692CE6B11FB540E52B3CC370
Form Name: loginForm
Input Name: password

Mitigation

(1) Protect information stored in cache. (2) Use a restrictive caching policy for forms and web pages that potentially contain sensitive information. (3) Do not store unnecessarily sensitive information in the cache. (4) Consider using encryption in the cache. (5) Disable autocomplete for sensitive form fields.

References

Warning
2533039

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2533043

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Apache-Coyote/1.1

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2533032

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2533033

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2533034

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2533036

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2533037

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2533041

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2533044

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning


Application Security Results for https://epht.example.com (11)

ID Finding Status
2533502

APPSEC Information Exposure Through Comments (CWE-615)

An attacker who finds these comments can map the application's structure and files, expose hidden parts of the site, and study the fragments of code to reverse engineer the application, which may help develop further attacks against the site.
Sensitive comment found: 
<!-- this script routes async Error to the EndRequestHandler, where it can redirect users to the error page -->

Mitigation

Remove comments which have sensitive information about the design/implementation of the application. Some of the comments may be exposed to the user and affect the security posture of the application.

References

Failed
2533508

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: npufd5d4eajjywkhsjiceso4
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2533483

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2533485

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2533481

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2533482

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2533484

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2533487

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2533489

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2533490

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2533492

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning


Application Security Results for https://tillamookfc.com (11)

ID Finding Status
2537621

APPSEC HTTPS website includes references from insecure (HTTP) resources (CWE-807)

Mixed content includes resources that can greatly change the behavior of a website, such as JavaScript, CSS, fonts, and iframes. Browsers may refuse to load active mixed content, which often results in affected pages being completely unstyled or broken. Browsers treat these very aggressively because of the consequences if they were compromised. For example, a single compromised Javascript file compromises the entire website, regardless of how other resources are loaded.

Url: http://tillamookfc.com/wp-content/uploads/2017/09/TFClogoHoriz.png
Tag: img

Url: http://tillamookfc.com/wp-content/uploads/2016/03/TFCSee.jpg
Tag: img

Url: http://tillamookfc.com/wp-content/uploads/2016/03/TFCHear.jpg
Tag: img

Url: http://tillamookfc.com/wp-content/uploads/2016/03/TFCTouch.jpg
Tag: img

Url: http://tillamookfc.com/wp-content/uploads/2016/03/TFCSmell.jpg
Tag: img

Url: http://tillamookfc.com/wp-content/uploads/2016/03/WebCam-1.jpg
Tag: img

Url: http://tillamookfc.com/wp-content/uploads/2017/09/TFCfavicon.png
Tag: link

Mitigation

Enable https for your website, but don’t force a redirect. Continue to present the http version as the canonical URL to search engines. Identify the most obvious and widespread pieces of mixed content by loading your website in a browser over https and observing breakages. Chrome, Opera, and Firefox will log any mixed content warnings to the console, which should point out necessary site-wide changes. Use these to secure your resource links. After fixing them, tackle the long tail by scanning your code and crawling your website. Finally, force the redirect to HTTPS, turn on HSTS, and tell search engines that your new URL starts with https.

References

Failed
2537598

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2537607

APPSEC Http Security Header X-Powered-By (CWE-200)

The X-Powered-By header gives information on the technology that's supporting the Web Server. With typical values like ASP.NET or PHP/5.4.0, this is another piece of information that we can remove from public display.
X-Powered-By Value: PHP/5.6.31

Mitigation

An origin server SHOULD NOT generate a X-Powered-By field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2537597

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2537599

APPSEC Http Security Header Cache-control (CWE-524)

Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Cache-control: no-store"
Cache-control header not found

Mitigation

Do not store unnecessarily sensitive information in the cache.

References

Warning
2537600

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2537601

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2537602

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2537603

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2537604

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2537606

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning


Application Security Results for http://sexoffenders.example.com (10)

ID Finding Status
2531200

APPSEC Cross-Site Request Forgery (CSRF) (CWE-352)

Cross-site request forgery (CSRF) vulnerabilities may arise when applications rely solely on HTTP cookies to identify the user that has issued a particular request. Because browsers automatically add cookies to requests regardless of their origin, it may be possible for an attacker to create a malicious web site that forges a cross-domain request to the vulnerable application.

Form Action: /SorPublic/Web.dll/main
Form Name: myform
 Input Name: I
 Input Name: cmd
 Input Name: I_AGREE_TO_CONDITIONS

Mitigation

The most effective way to protect against CSRF vulnerabilities is to include within relevant requests an additional token that is not transmitted in a cookie: for example, a parameter in a hidden form field. This additional token should contain sufficient entropy, and be generated using a cryptographic random number generator, such that it is not feasible for an attacker to determine or predict the value of any token that was issued to another user. The token should be associated with the user's session, and the application should validate that the correct token is received before performing any action resulting from the request.

References

Failed
2531172

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2531182

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2531173

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2531175

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2531177

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2531178

APPSEC Http Security Header Cache-control (CWE-524)

Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Cache-control: no-store"
Cache-control header not found

Mitigation

Do not store unnecessarily sensitive information in the cache.

References

Warning
2531179

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2531181

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2531183

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning


Application Security Results for https://call.uc.example.com (10)

ID Finding Status
2532532

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2532519

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2532522

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2532517

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2532518

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2532520

APPSEC Http Security Header Cache-control (CWE-524)

Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Cache-control: no-store"
Cache-control header not found

Mitigation

Do not store unnecessarily sensitive information in the cache.

References

Warning
2532521

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2532527

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2532528

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2532529

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning


Application Security Results for https://tspc.example.com (10)

ID Finding Status
2532758

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2532744

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.0

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2532745

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2532743

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2532746

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2532747

APPSEC Http Security Header Cache-control (CWE-524)

Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Cache-control: no-store"
Cache-control header not found

Mitigation

Do not store unnecessarily sensitive information in the cache.

References

Warning
2532748

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2532750

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2532753

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2532754

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning


Application Security Results for http://epht.example.com (10)

ID Finding Status
2533470

APPSEC Information Exposure Through Comments (CWE-615)

An attacker who finds these comments can map the application's structure and files, expose hidden parts of the site, and study the fragments of code to reverse engineer the application, which may help develop further attacks against the site.
Sensitive comment found: 
<!-- this script routes async Error to the EndRequestHandler, where it can redirect users to the error page -->

Mitigation

Remove comments which have sensitive information about the design/implementation of the application. Some of the comments may be exposed to the user and affect the security posture of the application.

References

Failed
2533451

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2533453

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2533449

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2533450

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2533452

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2533455

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2533457

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2533458

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2533460

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning


Application Security Results for https://www.yourwater.example.com (10)

ID Finding Status
2534066

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2534058

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2534059

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2534051

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2534053

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2534054

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2534055

APPSEC Http Security Header Cache-control (CWE-524)

Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Cache-control: no-store"
Cache-control header not found

Mitigation

Do not store unnecessarily sensitive information in the cache.

References

Warning
2534060

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2534061

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2534062

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning


Application Security Results for https://icaa.oha.example.com (10)

ID Finding Status
2531709

APPSEC HTTPS website includes references from insecure (HTTP) resources (CWE-807)

Mixed content includes resources that can greatly change the behavior of a website, such as JavaScript, CSS, fonts, and iframes. Browsers may refuse to load active mixed content, which often results in affected pages being completely unstyled or broken. Browsers treat these very aggressively because of the consequences if they were compromised. For example, a single compromised Javascript file compromises the entire website, regardless of how other resources are loaded.

Url: http://www.example.com/OHA/Style%20Library/Images/oha-logo-white.svg
Tag: img

Mitigation

Enable https for your website, but don’t force a redirect. Continue to present the http version as the canonical URL to search engines. Identify the most obvious and widespread pieces of mixed content by loading your website in a browser over https and observing breakages. Chrome, Opera, and Firefox will log any mixed content warnings to the console, which should point out necessary site-wide changes. Use these to secure your resource links. After fixing them, tackle the long tail by scanning your code and crawling your website. Finally, force the redirect to HTTPS, turn on HSTS, and tell search engines that your new URL starts with https.

References

Failed
2531711

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: UKuV-xKJpa3eY7yM2x8PK8YvzNM1OBJWZepAULKiq4HIwpDs7mUSYlXYX4JDOyFBDRu204aBtVk_UIMKPSqh5vc-V-EPPafpBBaME6v_GxY1
Cookie Name: __RequestVerificationToken
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2531686

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2531690

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2531683

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2531687

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2531689

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2531691

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2531692

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2531695

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning


Application Security Results for https://racedo.ets.example.com (9)

ID Finding Status
2533559

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2533572

APPSEC Cookie without HttpOnly flag set (CWE-87)

If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie's value via an injected script.

Cookie ID: deleted
Cookie Name: MRHSession
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: F5_ST
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: MRHSHint
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: F5_HT_shrinked
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: F5_fullWT
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: MRHSequence
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Mitigation

There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.

References

Warning
2533573

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: deleted
Cookie Name: MRHSession
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: F5_ST
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: MRHSHint
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: F5_HT_shrinked
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: F5_fullWT
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: MRHSequence
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2533549

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2533544

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2533545

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2533547

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2533550

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2533553

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning


Application Security Results for https://mail.doc.example.com (9)

ID Finding Status
2534289

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2534285

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2534277

APPSEC Http Security Header Cache-control (CWE-524)

Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Cache-control: no-store"
Cache-control header not found

Mitigation

Do not store unnecessarily sensitive information in the cache.

References

Warning
2534278

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2534279

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2534280

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2534283

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2534286

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2534287

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning


Application Security Results for https://exampleboa.com (9)

ID Finding Status
2538222

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2538211

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2538208

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2538209

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2538213

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2538215

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2538216

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2538217

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2538218

APPSEC Http Security Header Cache-control (CWE-524)

Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Cache-control: no-store"
Cache-control header not found

Mitigation

Do not store unnecessarily sensitive information in the cache.

References

Warning


Application Security Results for https://raohix.ets.example.com (8)

ID Finding Status
2532244

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2532257

APPSEC Cookie without HttpOnly flag set (CWE-87)

If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie's value via an injected script.

Cookie ID: deleted
Cookie Name: MRHSession
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: F5_ST
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: MRHSHint
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: F5_HT_shrinked
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: F5_fullWT
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: MRHSequence
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Mitigation

There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.

References

Warning
2532258

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: deleted
Cookie Name: MRHSession
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: F5_ST
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: MRHSHint
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: F5_HT_shrinked
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: F5_fullWT
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Cookie ID: deleted
Cookie Name: MRHSequence
Expires: Thu 01-Jan-1970 00:00:01 GMT
HTTPOnly: False
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2532231

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2532229

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2532239

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2532240

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2532241

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning


Application Security Results for https://gosgmp.org (8)

ID Finding Status
2537826

APPSEC The certificate is not valid, incorrect, expired or self-signed (CWE-295)

When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The software might connect to a malicious host while believing it is a trusted host, or the software might be deceived into accepting spoofed data that appears to originate from a trusted host.
certificate not valid for domain name

Mitigation

Certificates should be carefully managed and checked to assure that the server is using a certificate signed by a trusted CA.

References

Failed
2537817

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2537811

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2537813

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2537814

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2537819

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2537821

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2537823

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning


Application Security Results for https://ojdvsp.courts.example.com (5)

ID Finding Status
2531233

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: ../j_spring_security_check
Form ID: admin-login-form
 Input Name: j_username
 Input Name: j_password
 Input Name: logincontext

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2531206

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2531205

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2531210

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2531212

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning


Application Security Results for https://opdscore.courts.example.com (5)

ID Finding Status
2531649

APPSEC Improper restriction of excessive authentication attempts or login form without bot detection (CWE-307)

The software does not properly limit the number or frequency of interactions that it has with an actor, such as the number of incoming requests. This can allow the actor to perform actions more frequently than expected. The actor could be a human or an automated process such as a virus or bot. This could be used to cause a denial of service, compromise program logic (such as limiting humans to a single vote), or other consequences. For example, an authentication routine might not limit the number of times an attacker can guess a password. Or, a web site might conduct a poll but only expect humans to vote a maximum of once a day.

Form Action: ../j_spring_security_check
Form ID: admin-login-form
 Input Name: j_username
 Input Name: j_password
 Input Name: logincontext

Mitigation

Common protection mechanisms include: (1) Disconnecting the user after a small number of failed attempts (2) Implementing a timeout (3) Locking out a targeted account (4) Requiring a computational task on the user's part.

References

Failed
2531619

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2531623

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2531629

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2531631

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning


Application Security Results for https://licensesonline.dcbs.example.com (11)

ID Finding Status
2532031

APPSEC Cookie without HttpOnly flag set (CWE-87)

If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie's value via an injected script.

Cookie ID: EOHNCDBDFEBKJFDBMMJJPJLO
Cookie Name: ASPSESSIONIDSCAAQQSS
HTTPOnly: False
Path: /
Secure: False

Mitigation

There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.

References

Warning
2532032

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: EOHNCDBDFEBKJFDBMMJJPJLO
Cookie Name: ASPSESSIONIDSCAAQQSS
HTTPOnly: False
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2532009

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2532011

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.0

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2532004

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2532005

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2532006

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2532010

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2532013

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2532014

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2532016

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning


Application Security Results for http://teachin.example.com (11)

ID Finding Status
2532482

APPSEC Cookie without HttpOnly flag set (CWE-87)

If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie's value via an injected script.

Cookie ID: en
Cookie Name: pll_language
Expires: 31536000
HTTPOnly: False
Path: /
Secure: False

Mitigation

There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.

References

Warning
2532459

APPSEC Http Security Header X-Powered-By (CWE-200)

The X-Powered-By header gives information on the technology that's supporting the Web Server. With typical values like ASP.NET or PHP/5.4.0, this is another piece of information that we can remove from public display.
X-Powered-By Value: PHP/5.5.9-1ubuntu4.11

Mitigation

An origin server SHOULD NOT generate a X-Powered-By field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2532463

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2532454

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2532456

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2532457

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2532458

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2532462

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2532464

APPSEC Http Security Header Cache-control (CWE-524)

Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Cache-control: no-store"
Cache-control header not found

Mitigation

Do not store unnecessarily sensitive information in the cache.

References

Warning
2532465

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2532466

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning


Application Security Results for https://ojdvideomea.courts.example.com (11)

ID Finding Status
2533794

APPSEC Cookie without HttpOnly flag set (CWE-87)

If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie's value via an injected script.

Cookie ID: 2df78006c7c2799190fb1e918ccf1611b12dd000014a4262f247e3e7135bc696a6b9f61442e137dddd421130052b79c1
Cookie Name: _csrf
HTTPOnly: False
Path: /
Secure: False

Mitigation

There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.

References

Warning
2533795

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: 2df78006c7c2799190fb1e918ccf1611b12dd000014a4262f247e3e7135bc696a6b9f61442e137dddd421130052b79c1
Cookie Name: _csrf
HTTPOnly: False
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2533769

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2533768

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2533772

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2533773

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2533774

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2533775

APPSEC Http Security Header Cache-control (CWE-524)

Unless directed otherwise, browsers may store a local cached copy of content received from web servers. Some browsers, including Internet Explorer, cache content accessed via HTTPS. If sensitive information in application responses is stored in the local cache, then this may be retrieved by other users who have access to the same computer at a future time. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Cache-control: no-store"
Cache-control header not found

Mitigation

Do not store unnecessarily sensitive information in the cache.

References

Warning
2533776

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2533777

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2533780

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning


Application Security Results for https://billing.ets.example.com (10)

ID Finding Status
2530912

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: xrajbh45hqujjl5553vwgvml
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2530886

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2530893

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2530885

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2530888

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2530889

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2530890

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2530891

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2530892

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2530894

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning


Application Security Results for https://rps.licenseeservices.extportal.example.com (10)

ID Finding Status
2531136

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: m0vix2a5ddggjnfakcitp5af
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2531114

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2531119

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2531108

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2531111

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2531112

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2531115

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2531116

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2531118

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2531120

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning


Application Security Results for http://extportal.example.com (10)

ID Finding Status
2531423

APPSEC Cookie without HttpOnly flag set (CWE-87)

If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie's value via an injected script.

Cookie ID: rd1530o00000000000000000000ffffac1f217bo80
Cookie Name: BIGipServer~Example~OR-prd-moss.pool
HTTPOnly: False
Path: /
Secure: False

Mitigation

There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.

References

Warning
2531403

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2531406

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2531395

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2531396

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2531398

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2531399

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2531400

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2531401

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2531402

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning


Application Security Results for http://editors.extportal.example.com (10)

ID Finding Status
2531807

APPSEC Cookie without HttpOnly flag set (CWE-87)

If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie's value via an injected script.

Cookie ID: rd1530o00000000000000000000ffffac1f217bo80
Cookie Name: BIGipServer~Example~OR-prd-moss.pool
HTTPOnly: False
Path: /
Secure: False

Mitigation

There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.

References

Warning
2531779

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2531783

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2531781

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2531782

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2531784

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2531785

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2531787

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2531788

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2531789

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning


Application Security Results for https://wrdemail-archive.example.com (10)

ID Finding Status
2532096

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: thnhz51w2mxh30ru2e1jvtv4
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2532069

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2532075

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2532068

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2532072

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2532073

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2532076

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2532077

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2532078

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2532080

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning


Application Security Results for http://hrlb.example.com (10)

ID Finding Status
2532290

APPSEC Cookie without HttpOnly flag set (CWE-87)

If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie's value via an injected script.

Cookie ID: rd1530o00000000000000000000ffffac1f217eo80
Cookie Name: BIGipServer~Example~OR-prd-moss.pool
HTTPOnly: False
Path: /
Secure: False

Mitigation

There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.

References

Warning
2532267

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2532273

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2532262

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2532264

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2532265

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2532270

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2532271

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2532272

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2532274

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning


Application Security Results for https://rps.xray.example.com (10)

ID Finding Status
2532610

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: 4zez1rohztleuisv52pqugjz
Cookie Name: ASP.NET_SessionId
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2532583

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2532591

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2532582

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2532584

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2532587

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2532588

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2532592

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2532593

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2532594

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning


Application Security Results for https://mmdapply.example.com (10)

ID Finding Status
2533605

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: VYG8-9AT_F7CWms2IiA_S2lEbzZhKGPVmglO3j1p7QtMhTWIU6t0B9ag8ynEjRQqmh8D8h8GAlzlSkItAQ5m3Zk5qbjxC6GlAGng9qKC8hWRuVCbD0jYiOQYDMVS6KQWaa2MmdApNZDyCoVG_nwzVg2
Cookie Name: __RequestVerificationToken
HTTPOnly: True
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References

Warning
2533577

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2533582

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/7.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2533578

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2533580

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2533581

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2533583

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2533584

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning
2533585

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2533589

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning


Application Security Results for http://gis.example.com (10)

ID Finding Status
2533764

APPSEC Cookie without HttpOnly flag set (CWE-87)

If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie's value via an injected script.

Cookie ID: rd1530o00000000000000000000ffffac1f217do80
Cookie Name: BIGipServer~Example~OR-prd-moss.pool
HTTPOnly: False
Path: /
Secure: False

Mitigation

There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.

References

Warning
2533742

APPSEC Http Security Header Server (CWE-200)

The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server Value: Microsoft-IIS/8.5

Mitigation

An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties.

References

Warning
2533743

APPSEC Http Security Header Strict-Transport-Security (CWE-311)

HTTP Strict Transport Security is an excellent feature to support on your site and strengthens your implementation of TLS by getting the User Agent to enforce the use of HTTPS. Recommended value "strict-transport-security: max-age=31536000; includeSubDomains"
Strict-Transport-Security header not found

Mitigation

HTTP Strict Transport Security (HSTS) is a policy mechanism that allows a web server to enforce the use of TLS in a compliant User Agent (UA), such as a web browser. HSTS allows for a more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.

References

Warning
2533737

APPSEC Http Security Header X-Content-Type-Options (CWE-79)

X-Content-Type-Options stops a browser from trying to MIME-sniff the content type and forces it to stick with the declared content-type. The only valid value for this header is "X-Content-Type-Options: nosniff"
X-Content-Type-Options header not found

Mitigation

Always use the only defined value, nosniff.

References

Warning
2533738

APPSEC Http Security Header Public-Key-Pins (CWE-295)

HTTP Public Key Pinning protects your site from MiTM attacks using rogue X.509 certificates. By whitelisting only the identities that the browser should trust, your users are protected in the event a certificate authority is compromised.
Public-Key-Pins header not found

Mitigation

Deploying Public Key Pinning (PKP) safely will require operational and organizational maturity due to the risk that hosts may make themselves unavailable by pinning to a set of SPKIs that becomes invalid. With care, host operators can greatly reduce the risk of man-in-the-middle (MITM) attacks and other false- authentication problems for their users without incurring undue risk. PKP is meant to be used together with HTTP Strict Transport Security (HSTS) [RFC6797], but it is possible to pin keys without requiring HSTS.

References

Warning
2533739

APPSEC Http Security Header Pragma (CWE-524)

The Pragma general-header field is used to include implementation- specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Ideally, the web server should return the following HTTP headers in all responses containing sensitive content: "Pragma: no-store"
Pragma header not found

Mitigation

The Pragma header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored. Define "Pragma: no-cache" whenever is possible.

References

Warning
2533740

APPSEC Http Security Header Accept-Ranges (CWE-400)

Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts.
Accept-Ranges header not found

Mitigation

Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason.

References

Warning
2533741

APPSEC Http Security Header X-XSS-Protection (CWE-79)

X-XSS-Protection sets the configuration for the cross-site scripting filter built into most browsers. Recommended value "X-XSS-Protection: 1; mode=block"
X-XSS-Protection header not found

Mitigation

Use "X-XSS-Protection: 1; mode=block" whenever is possible

References

Warning
2533745

APPSEC Http Security Header X-Frame-Options (CWE-693)

X-Frame-Options tells the browser whether you want to allow your site to be framed or not. By preventing a browser from framing your site you can defend against attacks like clickjacking. Recommended value "x-frame-options: SAMEORIGIN"
X-Frame-Options header not found

Mitigation

In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options] and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking. Please check here https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet what's the best option for your case.

References

Warning
2533747

APPSEC Http Security Header Content-Security-Policy (CWE-79)

Content Security Policy is an effective measure to protect your site from XSS attacks. By whitelisting sources of approved content, you can prevent the browser from loading malicious assets.
Content-Security-Policy header not found

Mitigation

Content Security Policy is delivered via a HTTP response header, much like HSTS, and defines approved sources of content that the browser may load. It can be an effective countermeasure to Cross Site Scripting (XSS) attacks and is also widely supported and usually easily deployed.

References

Warning


Application Security Results for https://publicaccess.courts.example.com (10)

ID Finding Status
2533825

APPSEC Cookie without HttpOnly flag set (CWE-87)

If the HttpOnly attribute is set on a cookie, then the cookie's value cannot be read or set by client-side JavaScript. This measure makes certain client-side attacks, such as cross-site scripting, slightly harder to exploit by preventing them from trivially capturing the cookie's value via an injected script.

Cookie ID: 1234
Cookie Name: f5_cspm
HTTPOnly: False
Secure: False

Cookie ID: 019811484b7233af04ff76173ea8e24617e7b1885e5363ae6e5eb9246b27f9c57d12ce48a4740bc43339f20a8a24a5ba03ad8661480202179132da10ef7dd1f3ecaf126ccbf8cdd5ff4d00f003a962498484e99a28a24466fbda43c858341f3c87691553fd
Cookie Name: TS012e0a85
HTTPOnly: False
Path: /
Secure: False

Mitigation

There is usually no good reason not to set the HttpOnly flag on all cookies. Unless you specifically require legitimate client-side scripts within your application to read or set a cookie's value, you should set the HttpOnly flag by including this attribute within the relevant Set-cookie directive.

References

Warning
2533826

APPSEC Sensitive Cookie in HTTPS Session Without secure Attribute (CWE-614)

This attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed over unencrypted requests. If the application can be accessed over both HTTP and HTTPS, then there is the potential that the cookie can be sent in clear text.

Cookie ID: 1234
Cookie Name: f5_cspm
HTTPOnly: False
Secure: False

Cookie ID: 019811484b7233af04ff76173ea8e24617e7b1885e5363ae6e5eb9246b27f9c57d12ce48a4740bc43339f20a8a24a5ba03ad8661480202179132da10ef7dd1f3ecaf126ccbf8cdd5ff4d00f003a962498484e99a28a24466fbda43c858341f3c87691553fd
Cookie Name: TS012e0a85
HTTPOnly: False
Path: /
Secure: False

Mitigation

Always set the secure attribute when the cookie should sent via HTTPS only.

References