root
actions without giving full root
access. The CAP_SYS_ADMIN
capability grants the permission to perform the widest possible range of system administration operations to a Pod.CAP_SYS_ADMIN
capability to a container in a Pod.
...
kind: Pod
...
spec:
containers:
...
securityContext:
capabilities:
add:
- CAP_SYS_ADMIN
- SYS_TIME
...
ANYONE
role.ANYONE
role, it indicates that access control for the application has not been fully thought through or that the application is structured in such a way that reasonable access control restrictions are impossible.ANYONE
permission to invoke the Employee
EJB's method named getSalary()
.
<ejb-jar>
...
<assembly-descriptor>
<method-permission>
<role-name>ANYONE</role-name>
<method>
<ejb-name>Employee</ejb-name>
<method-name>getSalary</method-name>
</method-permission>
</assembly-descriptor>
...
</ejb-jar>
SameSite
parameter on session cookies is not set to Strict
.SameSite
parameter limits the scope of the cookie so that it is only attached to a request if the request is generated from first-party or same-site context. This helps to protect cookies from Cross-Site Request Forgery (CSRF) attacks. The SameSite
parameter can have the following three values:Strict
, cookies are only sent along with requests upon top-level navigation.Lax
, cookies are sent with top-level navigation from the same host as well as GET requests originated to the host from third-party sites. For example, suppose a third-party site has either iframe
or href
tags that link to the host site. If a user follows the link, the request will include the cookie.SameSite
parameter to Lax
for session cookies.
...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'Lax');
...
SameSite
attribute on session cookies is not set to Strict
.SameSite
attribute protects cookies from attacks such as Cross-Site Request Forgery (CSRF). Session cookies represent a user to the site so that the user can perform authorized actions. However, the browser automatically sends the cookies with the request and therefore users and web sites implicitly trust the browser for authorization. An attacker can misuse this trust and make a request to the site on behalf of the user by embedding links inside the href
and src
attribute of tags such as link
and iframe
in third-party site pages that an attacker controls. If an attacker is able to lure an unsuspecting user to the third-party site that they control, the attacker can make requests that automatically include the session cookie authorizing the user, effectively authorizing the attacker as if they were the user.SameSite
attribute to Strict
in session cookies. This restricts the browser to append cookies only to requests that are either top-level navigation or originate from the same site. Requests that originate from third-party sites via links in various tags such as iframe
, img
, and form
do not have these cookies and therefore prevent the site from taking action that the user might not have authorized.SameSite
attribute to Lax
for session cookies.
...
CookieOptions opt = new CookieOptions()
{
SameSite = SameSiteMode.Lax;
};
context.Response.Cookies.Append("name", "Foo", opt);
...
SameSite
attribute on session cookies is not set to SameSiteStrictMode
.SameSite
attribute protects cookies from attacks such as Cross-Site Request Forgery (CSRF). Session cookies represent a user to the site so that the user can perform authorized actions. However, the browser automatically sends the cookies with the request and therefore users and web sites implicitly trust the browser for authorization. An attacker can misuse this trust and make a request to the site on behalf of the user by embedding links inside the href
and src
attribute of tags such as link
and iframe
in third-party site pages that an attacker controls. If an attacker is able to lure an unsuspecting user to the third-party site that they control, the attacker can make requests that automatically include the session cookie authorizing the user, effectively authorizing the attacker as if they were the user.SameSiteStrictMode
for the SameSite
attribute, which restricts the browser to append cookies only to requests that are either top-level navigation or originate from the same site. Requests that originate from third-party sites via links in various tags such as iframe
, img
, and form
do not have these cookies and therefore prevent the site from taking action that the user might not have authorized.SameSiteLaxMode
in the SameSite
attribute for session cookies.
c := &http.Cookie{
Name: "cookie",
Value: "samesite-lax",
SameSite: http.SameSiteLaxMode,
}
SameSite
attribute on session cookies is not set to Strict
.SameSite
attribute protects cookies from attacks such as Cross-Site Request Forgery (CSRF). Session cookies represent a user to the site so that the user can perform authorized actions. However, the browser automatically sends the cookies with the request and therefore users and web sites implicitly trust the browser for authorization. An attacker can misuse this trust and make a request to the site on behalf of the user by embedding links inside the href
and src
attribute of tags such as link
and iframe
in third-party site pages that an attacker controls. If an attacker is able to lure an unsuspecting user to the third-party site that they control, the attacker can make requests that automatically include the session cookie authorizing the user, effectively authorizing the attacker as if they were the user.SameSite
attribute to Strict
in session cookies. This restricts the browser to append cookies only to requests that are either top-level navigation or originate from the same site. Requests that originate from third-party sites via links in various tags such as iframe
, img
, and form
do not have these cookies and therefore prevent the site from taking action that the user might not have authorized.SameSite
attribute to Lax
for session cookies.
app.get('/', function (req, res) {
...
res.cookie('name', 'Foo', { sameSite: "Lax" });
...
}
SameSite
attribute on session cookies is not set to Strict
.SameSite
attribute protects cookies from attacks such as Cross-Site Request Forgery (CSRF). Session cookies represent a user to the site so that the user can perform authorized actions. However, the browser automatically sends the cookies with the request and therefore users and web sites implicitly trust the browser for authorization. An attacker can misuse this trust and make a request to the site on behalf of the user by embedding links inside the href
and src
attribute of tags such as link
and iframe
in third-party site pages that an attacker controls. If an attacker is able to lure an unsuspecting user to the third-party site that they control, the attacker can make requests that automatically include the session cookie authorizing the user, effectively authorizing the attacker as if they were the user.Strict
for the SameSite
attribute, which restricts the browser to append cookies only to requests that are either top-level navigation or originate from the same site. Requests that originate from third-party sites via links in various tags such as iframe
, img
, and form
do not have these cookies and therefore prevent the site from taking action that the user might not have authorized.Lax
mode in the SameSite
attribute for session cookies.
session.cookie_samesite=Lax
SameSite
attribute on session cookies is not set to Strict
.SameSite
attribute protects cookies from attacks such as Cross-Site Request Forgery (CSRF). Session cookies represent a user to the site so that the user can perform authorized actions. However, the browser automatically sends the cookies with the request and therefore users and web sites implicitly trust the browser for authorization. An attacker can misuse this trust and make a request to the site on behalf of the user by embedding links inside the href
and src
attribute of tags such as link
and iframe
in third-party site pages that an attacker controls. If an attacker lures an unsuspecting user to the third-party site that they control, the attacker can make requests that automatically include the session cookie with user authorization. This effectively gives the attacker access with the user's authorization.Strict
for the SameSite
parameter, which restricts the browser to append cookies only to requests that are either top-level navigation or originate from the same site. Requests that originate from third-party sites via links in various tags such as iframe
, img
, and form
do not have these cookies and therefore prevent the site from taking action that the user might not have authorized.Lax
in the samesite
attribute for session cookies.
response.set_cookie("cookie", value="samesite-lax", samesite="Lax")
Unsafe-URL
might cause applications to expose sensitive site and user data (including session token, usernames and passwords) to third-party sites.Referrer-Policy
header is introduced to control browser behavior related to the referrer header. The Unsafe-URL
option removes all restrictions and sends the referrer header with every request.
<http auto-config="true">
...
<headers>
...
<referrer-policy policy="unsafe-url"/>
</headers>
</http>
WebMessage message = new WebMessage(WEBVIEW_MESSAGE);
webview.postWebMessage(message, Uri.parse("*"));
*
as the value of the target origin indicates that the script is sending a message to a window regardless of its origin.
o.contentWindow.postMessage(message, '*');
*
as the value of the target origin indicates that the script is sending a message to a window regardless of its origin.crossdomain.xml
configuration file. Starting with Flash Player 9,0,124,0, Adobe also introduced the capability to define which custom headers Flash Player can send across domains. However, caution should be taken when defining these settings because an overly permissive custom headers policy, when applied together with the overly permissive cross-domain policy, will allow a malicious application to send headers of their choosing to the target application, potentially leading to a variety of attacks or causing errors in the execution of the application that does not know how to handle received headers.
<cross-domain-policy>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>
*
as the value of the headers
attribute indicates that any header will be sent across domains.script-src
, img-src
, object-src
, style_src
, font-src
, media-src
, frame-src
, connect-src
. These 8 directives take a source list as a value that specifies domains the site is allowed to access for a feature covered by that directive. Developers can use a wildcard *
to indicate all or part of the source. Additional source list keywords such as 'unsafe-inline'
and 'unsafe-eval'
provide more granular control over script execution but are potentially harmful. None of the directives are mandatory. Browsers either allow all sources for an unlisted directive or derive its value from the optional default-src
directive. Furthermore, the specification for this header has evolved over time. It was implemented as X-Content-Security-Policy
in Firefox until version 23 and in IE until version 10, and was implemented as X-Webkit-CSP
in Chrome until version 25. Both of these names are deprecated in favor of the now standard name Content Security Policy
. Given the number of directives, two deprecated alternate names, and the way multiple occurrences of the same header and repeated directives in a single header are treated, there is a high probability that a developer can misconfigure this header.default-src
directive:
<http auto-config="true">
...
<headers>
...
<content-security-policy policy-directives="default-src '*'" />
</headers>
</http>
script-src
, img-src
, object-src
, style_src
, font-src
, media-src
, frame-src
, connect-src
. These 8 directives take a source list as a value that specifies domains the site is allowed to access for a feature covered by that directive. Developers can use a wildcard *
to indicate all or part of the source. Additional source list keywords such as 'unsafe-inline'
and 'unsafe-eval'
provide more granular control over script execution but are potentially harmful. None of the directives are mandatory. Browsers either allow all sources for an unlisted directive or derive its value from the optional default-src
directive. Furthermore, the specification for this header has evolved over time. It was implemented as X-Content-Security-Policy
in Firefox until version 23 and in IE until version 10, and was implemented as X-Webkit-CSP
in Chrome until version 25. Both of these names are deprecated in favor of the now standard name Content Security Policy
. Given the number of directives, two deprecated alternate names, and the way multiple occurrences of the same header and repeated directives in a single header are treated, there is a high probability that a developer can misconfigure this header.*-src
directive has been configured with an overly permissive policy such as *
Example 1: The following django-csp
setting sets an overly permissive and insecure default-src
directive:
...
MIDDLEWARE_CLASSES = (
...
'csp.middleware.CSPMiddleware',
...
)
...
CSP_DEFAULT_SRC = ("'self'", '*')
...