SameSite em cookies de sessão.SameSite limita o escopo do cookie para que ele seja anexado apenas a uma solicitação se a solicitação for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O parâmetro SameSite pode ter os três seguintes valores:Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.SameSite como None para cookies de sessão.
...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'None');
...
SameSite em cookies de sessão.SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas de sites de terceiros, incluindo aqueles que têm as tags iframe ou href vinculadas ao site host. Se um usuário seguir o link, a solicitação incluirá o cookie.SameSite para cookies de sessão.
...
CookieOptions opt = new CookieOptions()
{
SameSite = SameSiteMode.None;
};
context.Response.Cookies.Append("name", "Foo", opt);
...
SameSite em cookies de sessão.SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.SameSite para cookies de sessão.
c := &http.Cookie{
Name: "cookie",
Value: "samesite-none",
SameSite: http.SameSiteNoneMode,
}
SameSite em cookies de sessão.SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas de sites de terceiros, incluindo aqueles que têm as tags iframe ou href vinculadas ao site host. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.SameSite para cookies de sessão.
ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue")
...
.sameSite("None")
...
SameSite em cookies de sessão.SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas de sites de terceiros, incluindo aqueles que têm as tags iframe ou href vinculadas ao site host. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.SameSite para cookies de sessão.
app.get('/', function (req, res) {
...
res.cookie('name', 'Foo', { sameSite: false });
...
}
SameSite em cookies de sessão.SameSite limita o escopo do cookie de forma que ele só seja anexado a uma solicitação se ela for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O atributo SameSite pode ter os três seguintes valores:Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior. Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.SameSite para cookies de sessão.
ini_set("session.cookie_samesite", "None");
SameSite em cookies de sessão.samesite limita o escopo do cookie para que ele seja anexado apenas a uma solicitação se a solicitação for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O parâmetro samesite pode ter os três seguintes valores:Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.SameSite para cookies de sessão.
response.set_cookie("cookie", value="samesite-none", samesite=None)
.example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz logon.
HttpCookie cookie = new HttpCookie("sessionID", sessionID);
cookie.Domain = ".example.com";
http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com..example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies carregam frequentemente informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro aplicativo.http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz logon.
cookie := http.Cookie{
Name: "sessionID",
Value: getSessionID(),
Domain: ".example.com",
}
...
http://insecure.example.com/ e ele contenha uma vulnerabilidade de cross-site scripting. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.insecure.example.com para criar seu próprio cookie excessivamente amplo que substitui o cookie em Secure.example.com..example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz logon.
Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setDomain(".example.com");
http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com..example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz logon.
cookie_options = {};
cookie_options.domain = '.example.com';
...
res.cookie('important_cookie', info, cookie_options);
http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com..example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz logon.
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
[cookieProperties setValue:@".example.com" forKey:NSHTTPCookieDomain];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com..example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz logon.
setcookie("mySessionId", getSessionID(), 0, "/", ".example.com", true, true);
http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com..example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz logon.
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/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.insecure.example.com para criar o cookie próprio e excessivamente amplo que substitui o cookie secure.example.com..example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz logon.
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, domain = Some(".example.com")))
http://insecure.example.com/ e ele contenha uma vulnerabilidade de cross-site scripting. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com..example.com". Isso expõe o cookie a todos os aplicativos Web no domínio base e em quaisquer subdomínios. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando um usuário faz logon.
...
let properties = [
NSHTTPCookieDomain: ".example.com",
NSHTTPCookiePath: "/service",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar",
NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com.insecure.example.com para criar o seu próprio cookie excessivamente amplo que substitui o cookie de secure.example.com./"). Fazer isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies carregam frequentemente informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro aplicativo.http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum. Por exemplo:
...
String path = '/';
Cookie cookie = new Cookie('sessionID', sessionID, path, maxAge, true, 'Strict');
...
http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando a ID de sessão, o invasor pode comprometer a conta de qualquer usuário do fórum que tenha navegado até /EvilSite./EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum./". No entanto, fazer isso expõe o cookie a todos os aplicativos Web no mesmo domínio. Como cookies carregam frequentemente informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro aplicativo.http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.
HttpCookie cookie = new HttpCookie("sessionID", sessionID);
cookie.Path = "/";
http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite./EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum./"). Fazer isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies carregam frequentemente informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro aplicativo.http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.
cookie := http.Cookie{
Name: "sessionID",
Value: sID,
Expires: time.Now().AddDate(0, 0, 1),
Path: "/",
}
...
http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clica nesse link, o navegador envia o cookie definido por /MyForum para o aplicativo em execução em /EvilSite. Roubando a ID de sessão, o invasor pode comprometer a conta de qualquer usuário do fórum que tenha navegado até /EvilSite./EvilSite para criar seu próprio cookie excessivamente amplo que substitui o cookie em /MyForum./"). Isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.
Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setPath("/");
http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite./EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum./"). Isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.
cookie_options = {};
cookie_options.path = '/';
...
res.cookie('important_cookie', info, cookie_options);
http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite./EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum./"). Isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
[cookieProperties setValue:@"/" forKey:NSHTTPCookiePath];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite./EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum./"). Isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.
setcookie("mySessionId", getSessionID(), 0, "/", "communitypages.example.com", true, true);
http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite./EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum./"). Isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.
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 e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite./EvilSite para criar o cookie próprio e excessivamente amplo que substitui o cookie /MyForum./"). Isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, path = "/"))
http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite./EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum./"). Isso expõe o cookie a todos os aplicativos Web no domínio. Como cookies frequentemente contêm informações confidenciais, como identificadores de sessão, compartilhar cookies entre aplicativos pode fazer com que uma vulnerabilidade em um aplicativo comprometa outro.http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de ID de sessão com o caminho "/" quando os usuários fazem logon no fórum.
...
let properties = [
NSHTTPCookieDomain: "www.example.com",
NSHTTPCookiePath: "/",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar",
NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie definido por /MyForum ao aplicativo em execução em /EvilSite. Roubando o ID da sessão, o invasor consegue comprometer a conta de qualquer usuário do fórum que tiver navegado até /EvilSite./EvilSite para criar o seu próprio cookie excessivamente amplo que substitui o cookie de /MyForum..example.com". No entanto, fazer isso expõe o cookie de sessão a todos os aplicativos Web no nome do domínio base e em quaisquer subdomínios. O vazamento de cookies de sessão pode comprometer contas.http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando os usuários fazem login.
server.servlet.session.cookie.domain=.example.com
http://insecure.example.com/ e ele contenha uma vulnerabilidade de Cross-Site Scripting. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com..example.com". Isso expõe o cookie de sessão a todos os aplicativos Web sob o domínio base e todos os subdomínios. O compartilhamento de cookies de sessão entre aplicativos pode causar uma vulnerabilidade em um aplicativo, causando um comprometimento em outro.http://secure.example.com/ e esse aplicativo defina uma ID de cookie de sessão com o domínio ".example.com" quando os usuários fazem login.
session_set_cookie_params(0, "/", ".example.com", true, true);
http://insecure.example.com/ e ele contenha uma vulnerabilidade de criação de scripts entre sites. Qualquer usuário autenticado em http://secure.example.com que navegar até http://insecure.example.com correrá o risco de expor seu cookie de sessão de http://secure.example.com./"). Isso expõe o cookie a todos os aplicativos Web no mesmo domínio. O vazamento de cookies de sessão pode comprometer contas porque um invasor pode roubar o cookie de sessão usando uma vulnerabilidade em qualquer um dos aplicativos no domínio.http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de sessão com o caminho "/" quando os usuários fazem logon no fórum. Por exemplo:
server.servlet.session.cookie.path=/
http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie de sessão definido por /MyForum para o aplicativo em execução em /EvilSite. Usando o cookie de sessão fornecido pelo usuário em /MyForum, o invasor pode comprometer a conta de qualquer usuário do fórum que navegue para /EvilSite./"). Isso expõe o cookie a todos os aplicativos Web no mesmo domínio. O vazamento de cookies de sessão pode comprometer contas porque um invasor pode roubar o cookie de sessão usando uma vulnerabilidade em qualquer um dos aplicativos no domínio.http://communitypages.example.com/MyForum e esse aplicativo defina um cookie de sessão com o caminho "/" quando os usuários fazem logon no fórum.
session_set_cookie_params(0, "/", "communitypages.example.com", true, true);
http://communitypages.example.com/EvilSite e publique um link para esse site no fórum. Quando um usuário do fórum clicar nesse link, o navegador enviará o cookie de sessão definido por /MyForum para o aplicativo em execução em /EvilSite. Ao roubar o cookie de sessão, o invasor pode comprometer a conta de qualquer usuário do fórum que tenha navegado até /EvilSite.SameSite em cookies de sessão não está definido como Strict.SameSite limita o escopo do cookie para que ele seja anexado apenas a uma solicitação se a solicitação for gerada do contexto primário ou do mesmo site. Isso ajuda a proteger os cookies contra ataques CSRF (Cross-Site Request Forgery). O parâmetro SameSite pode ter os três seguintes valores:Strict, os cookies são enviados apenas com as solicitações na navegação de nível superior.Lax, os cookies são enviados com navegação de nível superior do mesmo host, bem como solicitações GET originadas para o host de sites de terceiros. Por exemplo, suponha que haja um site de terceiros que tenha tags iframe ou href para o site host. Se um usuário seguir o link, a solicitação incluirá o cookie.SameSite como Lax para cookies de sessão.
...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'Lax');
...
SameSite em cookies de sessão não está definido como Strict.SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.SameSite como Strict nos cookies de sessão. Isso restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.SameSite como Lax para cookies de sessão.
...
CookieOptions opt = new CookieOptions()
{
SameSite = SameSiteMode.Lax;
};
context.Response.Cookies.Append("name", "Foo", opt);
...
SameSite em cookies de sessão não é definido como SameSiteStrictMode.SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.SameSiteStrictMode para SameSite, o que restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.SameSiteLaxMode no atributo SameSite para cookies de sessão.
c := &http.Cookie{
Name: "cookie",
Value: "samesite-lax",
SameSite: http.SameSiteLaxMode,
}
SameSite em cookies de sessão não está definido como Strict.SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.SameSite como Strict nos cookies de sessão. Isso restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.SameSite como Lax para cookies de sessão.
ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue")
...
.sameSite("Lax")
...
}
SameSite em cookies de sessão não está definido como Strict.SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.SameSite como Strict nos cookies de sessão. Isso restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.SameSite como Lax para cookies de sessão.
app.get('/', function (req, res) {
...
res.cookie('name', 'Foo', { sameSite: "Lax" });
...
}
SameSite em cookies de sessão não é definido como Strict.SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor conseguir atrair um usuário desavisado para o site de terceiros que ele controla, ele poderá fazer solicitações que incluam automaticamente o cookie de sessão que autoriza o usuário, autorizando efetivamente o invasor como se fosse o usuário.Strict para SameSite, o que restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.Lax no atributo SameSite para cookies de sessão.
ini_set("session.cookie_samesite", "Lax");
SameSite em cookies de sessão não está definido como Strict.SameSite protege cookies contra ataques como CSRF (Cross-Site Request Forgery). Os cookies de sessão representam um usuário para o site para que ele possa executar ações autorizadas. No entanto, o navegador envia automaticamente os cookies com a solicitação e, portanto, os usuários e os sites confiam implicitamente no navegador para autorização. Um invasor pode usar indevidamente essa confiança e fazer uma solicitação ao site em nome do usuário incorporando links no atributo href e src de tags como link e iframe em páginas de sites de terceiros que um invasor controla. Se um invasor atrair um usuário desavisado para o site de terceiros que ele controla, o invasor poderá fazer solicitações que incluam automaticamente o cookie de sessão com autorização do usuário. Isso efetivamente dá ao invasor acesso com a autorização do usuário.Strict para o parâmetro SameSite, o que restringe o navegador a anexar cookies apenas a solicitações de navegação de nível superior ou originadas do mesmo site. Solicitações originadas de sites de terceiros por meio de links em várias tags, como iframe, img e form, não têm esses cookies e, portanto, evitam que o site execute ações que o usuário possa não ter autorizado.Lax no atributo samesite para cookies de sessão.
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)
...
server.servlet.session.cookie.persistent=true
session_set_cookie_params(time()+60*60*24*365*10, "/", "www.example.com", false, true);
Secure definido como true.Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.Secure.
...
<configuration>
<system.web>
<authentication mode="Forms">
<forms requireSSL="false" loginUrl="login.aspx">
</forms>
</authentication>
</system.web>
</configuration>
...
Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. O sniffing do tráfego de rede por meio de conexões sem fio não criptografadas é uma tarefa simples para os invasores e, portanto, o envio de cookies (especialmente aqueles com IDs de sessão) via HTTP pode comprometer o aplicativo.Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.Secure para cookies de sessão.
server.servlet.session.cookie.secure=false
Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.Secure como trueSecure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante quando o cookie contém dados privados ou carrega um identificador de sessão.Secure.
...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...
Secure, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.SESSION_COOKIE_SECURE como True ou a define como False .Secure para cada cookie. Se esse sinalizador estiver definido, o navegador apenas enviará o cookie via HTTPS. O envio de cookies através de um canal criptografado pode expô-los a ataques de sniffing de rede e, portanto, o sinalizador "secure" ajuda a manter o valor de um cookie confidencial. Isso é especialmente importante se o cookie contém dados privados, identificadores de sessão, ou carrega um token CSRF.Secure para os cookies de sessão.
...
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, os cookies enviados durante uma solicitação HTTPS também serão enviados durante as solicitações HTTP subsequentes. Dessa forma, os invasores poderão comprometer o cookie farejando o tráfego de rede não criptografado, o que é particularmente fácil em redes sem fio.
...
<cfquery name = "GetSSNs" dataSource = "users"
username = "scott" password = "tiger">
SELECT SSN
FROM Users
</cfquery>
...
...
Credentials.basic("hardcoded-username", password);
...
MyAccountActions e um método de ação de página pageAction(). O método pageAction() é executado quando o URL da página é visitado e o servidor não verifica se há tokens anti-CSRF.
<apex:page controller="MyAccountActions" action="{!pageAction}">
...
</apex:page>
public class MyAccountActions {
...
public void pageAction() {
Map<String,String> reqParams = ApexPages.currentPage().getParameters();
if (params.containsKey('id')) {
Id id = reqParams.get('id');
Account acct = [SELECT Id,Name FROM Account WHERE Id = :id];
delete acct;
}
}
...
}
<img src="http://my-org.my.salesforce.com/apex/mypage?id=YellowSubmarine" height=1 width=1/>
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
rb.sendRequest(body, new NewAccountCallback(callback));
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "http://www.example.com/new_user");
body = addToPost(body, "attacker";
body = addToPost(body, "haha");
rb.sendRequest(body, new NewAccountCallback(callback));
example.com acessar a página mal-intencionada enquanto tiver uma sessão ativa no site, criará involuntariamente uma conta para o invasor. Isso é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.
<http auto-config="true">
...
<csrf disabled="true"/>
</http>
var req = new XMLHttpRequest();
req.open("POST", "/new_user", true);
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
req.send(body);
var req = new XMLHttpRequest();
req.open("POST", "http://www.example.com/new_user", true);
body = addToPost(body, "attacker");
body = addToPost(body, "haha");
req.send(body);
example.com visitar a página maliciosa enquanto tiver uma sessão ativa no site, ela involuntariamente criará uma conta para o invasor. Isto é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>
<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>
example.com visitar a página maliciosa enquanto tiver uma sessão ativa no site, ela involuntariamente criará uma conta para o invasor. Isto é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.buyItem.
+ nocsrf
POST /buyItem controllers.ShopController.buyItem
shop.com, ela comprará itens involuntariamente para o invasor. Isso é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>
<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>
example.com visitar a página maliciosa enquanto tiver uma sessão ativa no site, ela involuntariamente criará uma conta para o invasor. Isto é um ataque de CSRF. Ele é possível porque o aplicativo não tem como determinar a procedência da solicitação. Qualquer solicitação pode ser uma ação legítima escolhida pelo usuário ou uma ação falsa criada por um invasor. O invasor não chega a ver a página da Web gerada pela solicitação falsa e, portanto, a técnica de ataque é útil somente para solicitações que alteram o estado do aplicativo.
@GetMapping("/ai")
String generation(String userInput) {
return this.chatClient.prompt()
.user(userInput)
.call()
.content();
}
message, e a exibe ao usuário.
const openai = new OpenAI({
apiKey: ...,
});
const chatCompletion = await openai.chat.completions.create(...);
message = res.choices[0].message.content
console.log(chatCompletion.choices[0].message.content)
val chatCompletionRequest = ChatCompletionRequest(
model = ModelId("gpt-3.5-turbo"),
messages = listOf(...)
)
val completion: ChatCompletion = openAI.chatCompletion(chatCompletionRequest)
response.getOutputStream().print(completion.choices[0].message)
message, e a exibe ao usuário.
client = openai.OpenAI()
res = client.chat.completions.create(...)
message = res.choices[0].message.content
self.writeln(f"<p>{message}<\p>")
chatService.createCompletion(
text,
settings = CreateCompletionSettings(...)
).map(completion =>
val html = Html(completion.choices.head.text)
Ok(html) as HTML
)
...
text/html. Portanto, o XSS só será possível se a resposta usar esse tipo MIME ou qualquer outro que também force o navegador a renderizar a resposta como HTML ou outro documento que possa executar scripts, como imagens SVG. (image/svg+xml), documentos XML (application/xml), etc. application/octet-stream. No entanto, alguns navegadores, como o Internet Explorer, executam o que é conhecido como Content Sniffing. O Content Sniffing envolve ignorar o tipo MIME fornecido e tentar inferir o tipo MIME correto pelo conteúdo da resposta.text/html é apenas um tipo MIME que pode levar a vulnerabilidades de XSS. Outros documentos que podem executar scripts, como imagens SVG (image/svg+xml), documentos XML (application/xml), assim como outros, podem levar a vulnerabilidades de XSS, independentemente de o navegador executar o Content Sniffing. <html><body><script>alert(1)</script></body></html>, poderia ser renderizada como HTML mesmo se seu cabeçalho content-type estivesse definido como application/octet-stream,multipart-mixed, e assim por diante.application/octet-stream.
@RestController
public class SomeResource {
@RequestMapping(value = "/test", produces = {MediaType.APPLICATION_OCTET_STREAM_VALUE})
public String response5(@RequestParam(value="name") String name){
return name;
}
}
name definido como <html><body><script>alert(1)</script></body></html>, o servidor produzirá a seguinte resposta:
HTTP/1.1 200 OK
Content-Length: 51
Content-Type: application/octet-stream
Connection: Closed
<html><body><script>alert(1)</script></body></html>
text/html. Portanto, o XSS só será possível se a resposta usar esse tipo MIME ou qualquer outro que também force o navegador a renderizar a resposta como HTML ou outro documento que possa executar scripts, como imagens SVG. (image/svg+xml), documentos XML (application/xml), etc. application/json. No entanto, alguns navegadores, como o Internet Explorer, executam o que é conhecido como Content Sniffing. O Content Sniffing envolve ignorar o tipo MIME fornecido e tentar inferir o tipo MIME correto pelo conteúdo da resposta.Vale a pena notar, no entanto, que um tipo MIME de text/html é apenas um tipo MIME que pode levar a vulnerabilidades de XSS. Outros documentos que podem executar scripts, como imagens SVG (image/svg+xml), documentos XML (application/xml), assim como outros, podem levar a vulnerabilidades de XSS, independentemente de o navegador executar o Content Sniffing. <html><body><script>alert(1)</script></body></html>, poderia ser renderizada como HTML, mesmo se o cabeçalho content-type estiver definido como application/json.application/json.
def mylambda_handler(event, context):
name = event['name']
response = {
"statusCode": 200,
"body": "{'name': name}",
"headers": {
'Content-Type': 'application/json',
}
}
return response
name definido como <html><body><script>alert(1)</script></body></html>, o servidor produzirá a seguinte resposta:
HTTP/1.1 200 OK
Content-Length: 88
Content-Type: application/json
Connection: Closed
{'name': '<html><body><script>alert(1)</script></body></html>'}
eid, de uma solicitação HTTP e o exibe para o usuário.
String queryString = Window.Location.getQueryString();
int pos = queryString.indexOf("eid=")+4;
HTML output = new HTML();
output.setHTML(queryString.substring(pos, queryString.length()));
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.eid, a partir de uma URL e a exibe ao usuário.Exemplo 2: Considere o formulário HTML:
<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<div id="myDiv">
Employee ID: <input type="text" id="eid"><br>
...
<button>Show results</button>
</div>
<div id="resultsDiv">
...
</div>
$(document).ready(function(){
$("#myDiv").on("click", "button", function(){
var eid = $("#eid").val();
$("resultsDiv").append(eid);
...
});
});
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.
let element = JSON.parse(getUntrustedInput());
ReactDOM.render(<App>
{element}
</App>);
Example 3, se um invasor conseguir controlar todo o objeto JSON recuperado de getUntrustedInput(), poderá fazer o React renderizar o element como um componente e, portanto, poderá passar um objeto com o dangerouslySetInnerHTML com seu próprio valor controlado, um típico ataque de Cross-Site Scripting.
<attribute name="href" onInvalid="filterTag">
<regexp-list>
<regexp name="onsiteURL"/>
<regexp name="offsiteURL"/>
</regexp-list>
</attribute>
eid, de uma solicitação HTTP e a exibe para o usuário.
String eid = Request["eid"];
...
EmployeeID.Text = eid;
EmployeeID é um controle ASP.NET no lado do servidor definido da seguinte maneira:
<form runat="server">
...
<asp:Label id="EmployeeID" runat="server"/>
...
</form>
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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 é um controle ASP.NET no lado do servidor definido da seguinte maneira:
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server"/>
...
</form>
Example 2, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.user, de uma solicitação HTTP e o exibe para o usuário.
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}
user contiver apenas texto alfanumérico padrão. Se user tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque a indireção causada pelo armazenamento de dados dificulta a identificação da ameaça e aumenta a possibilidade de o ataque afetar vários usuários. O XSS começou dessa forma, com sites que ofereciam um "livro de visitas" aos visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações XSS refletidas ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor poderá executar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais pertencentes ao usuário.
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...
url começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.eid, de uma solicitação HTTP e a exibe para o usuário.
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 3, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...
url começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.eid, de uma solicitação de servlet HTTP e, em seguida, exibe o valor de volta para o usuário na resposta do servlet.
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 3, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.
...
@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 contiver apenas um texto alfanumérico padrão. Se o texto no inputTextField incluir metacaracteres ou código-fonte, a entrada poderá ser executada como código pelo navegador da Web conforme exibe a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, uma fonte fora do aplicativo de destino faz uma solicitação de URL usando o esquema de URL personalizado do aplicativo de destino, e os dados não validados a partir da solicitação de URL subsequentemente são lidos pelo aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.Example 2, os dados são lidos diretamente de um componente de IU controlado pelo usuário e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 3, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.
...
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: é controlável pelo usuário e JavaScript é habilitado por padrão em um WKWebView, o usuário pode escrever conteúdo arbitrário (incluindo scripts executáveis) para o WKWebView por meio de solicitações que usam o esquema de URL personalizado do aplicativo.
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField contiver apenas um texto alfanumérico padrão. Se o texto no inputTextField incluir metacaracteres ou código-fonte, a entrada poderá ser executada como código pelo navegador da Web conforme exibe a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, uma fonte fora do aplicativo de destino faz uma solicitação de URL usando o esquema de URL personalizado do aplicativo de destino, e os dados não validados a partir da solicitação de URL subsequentemente são lidos pelo aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.Example 2, os dados são lidos diretamente de um componente de IU controlado pelo usuário e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 3, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.
...
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 apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.eid, de uma solicitação HTTP e a exibe para o usuário.
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.
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 apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.eid, de uma solicitação HTTP e a exibe para o usuário.
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, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
name estão bem definidos, assim como caracteres alfanuméricos, mas não faz nada para verificar se há dados mal-intencionados. Mesmo lido do banco de dados, o valor deve ser devidamente validado, pois o conteúdo do banco de dados pode ser proveniente de dados fornecidos pelo usuário. Dessa forma, um invasor pode ter comandos mal-intencionados executados no navegador da Web do usuário, sem a necessidade de interagir com a vítima como na XSS Refletida. Esse tipo de ataque, conhecido como XSS Armazenada (ou Persistente), pode ser muito difícil de detectar, pois os dados são indiretamente fornecidos para a função vulnerável e também têm um impacto maior devido à possibilidade de afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.username, e o exibe ao usuário.
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username contiver metacaracteres ou código-fonte, ele será executado pelo navegador da Web.Example 1, o banco de dados ou outro armazenamento de dados pode fornecer dados perigosos ao aplicativo que serão incluídos no conteúdo dinâmico. Do ponto de vista do invasor, o melhor lugar para armazenar conteúdo mal-intencionado é em uma área acessível a todos os usuários, especialmente para aqueles com privilégios elevados, que são mais propensos a lidar com informações confidenciais ou realizar operações críticas.Example 2, os dados são lidos na solicitação HTTP e refletidos de volta na resposta HTTP. A XSS Refletida ocorre quando um invasor pode ter conteúdo perigoso distribuído a um aplicativo Web vulnerável e, em seguida, refletido de volta para o usuário e executado por seu navegador. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é postada publicamente ou enviada por email diretamente para a vítima. As URLs criadas dessa forma são a essência de muitos esquemas de phishing, nos quais o invasor convence a vítima a visitar a URL. Depois que o site refletir o conteúdo de volta para o usuário, ele será executado e poderá realizar várias ações, como encaminhar informações confidenciais particulares, executar operações não autorizadas no computador da vítima, 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 é um controle de formulário definido da seguinte maneira:Exemplo 2: O seguinte segmento de código ASP.NET é funcionalmente equivalente ao
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 1, mas implementa todos os elementos de formulário programaticamente.
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 apresentam um comportamento satisfatório, mas não fazem nada para impedir explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Login e EmployeeID são controles de formulário definidos da seguinte maneira:Exemplo 4: O seguinte segmento de código ASP.NET mostra a maneira programática de implementar o
<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 e no Example 2, esses exemplos funcionarão corretamente se Login contiver apenas texto alfanumérico padrão. Se Login tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.Example 1 e no Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 3 e no Example 4, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.
...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.
EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...
ENAME apresentam um comportamento satisfatório, mas não faz nada para impedir explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de ENAME é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de ENAME for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Armazenado, é especialmente insidioso porque o engano causado pelo armazenamento de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque afete vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.EID, de um formulário HTML e o exibe para o usuário.
...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.
EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...
Example 1, esse código funcionará corretamente se EID contiver apenas texto alfanumérico padrão. Se EID tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS armazenadas ocorrem quando um invasor Example 2, os dados são lidos diretamente no Formulário HTML e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>
name apresentam um comportamento satisfatório, mas não faz nada para impedir explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.eid, de um formulário da Web e a exibe para o usuário.
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Example 1, esse código funcionará corretamente se Form.eid contiver apenas texto alfanumérico padrão. Se Form.eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.user, de uma solicitação HTTP e o exibe para o usuário.
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}
user contiver apenas texto alfanumérico padrão. Se user tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque a indireção causada pelo armazenamento de dados dificulta a identificação da ameaça e aumenta a possibilidade de o ataque afetar vários usuários. O XSS começou dessa forma, com sites que ofereciam um "livro de visitas" aos visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações XSS refletidas ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor poderá executar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais pertencentes ao usuário.
<%...
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 apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.eid, de uma solicitação HTTP e a exibe para o usuário.
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...
url começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 3, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo 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 apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.eid, a partir de uma solicitação HTTP e a exibe ao usuário.
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, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.
...
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 apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.eid, de uma solicitação de servlet HTTP e, em seguida, exibe o valor de volta para o usuário na resposta do servlet.
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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 começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 3, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.name apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.myapp://input_to_the_application). Os dados não confiáveis na URL são então utilizados para renderizar a saída HTML em um componente WebView.
...
- (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, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 2, os dados são lidos diretamente de um URL de esquema personalizado e refletidos de volta no conteúdo de uma resposta UIWebView. Os ataques de XSS refletido ocorrem quando um invasor faz com que um usuário forneça conteúdo perigoso a um aplicativo iOS vulnerável, o que é então refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a propagação de conteúdo malicioso é incluí-lo como um parâmetro em um URL de esquema personalizado veiculada publicamente ou diretamente por email para as vítimas. As URLs criadas dessa forma constituem o núcleo de muitos esquemas de phishing, em que um invasor convence as vítimas a visitar uma URL que se refere a um aplicativo vulnerável. Depois que o aplicativo reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.
<?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 apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.eid, de uma solicitação HTTP e a exibe para o usuário.
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.
...
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 apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.eid, a partir de uma solicitação HTTP e a exibe ao usuário.
...
-- 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, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.eid, a partir de uma solicitação HTTP e a exibe ao usuário.
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...
Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.
...
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 apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.eid, a partir de uma solicitação HTTP e a exibe ao usuário.
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
Example 1, o código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.Rack::Request#params() como no Example 2, ele verá os parâmetros GET e POST, então você pode estar vulnerável a vários tipos de outros ataques, e não apenas ter o código malicioso anexado à URL.Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.eid, de uma consulta de banco de dados e a exibe para o usuário.
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 apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField contiver apenas um texto alfanumérico padrão. Se o texto no inputTextField incluir metacaracteres ou código-fonte, a entrada poderá ser executada como código pelo navegador da Web conforme exibe a resposta HTTP.myapp://input_to_the_application). Os dados não confiáveis na URL são então utilizados para renderizar a saída HTML em um componente WebView.
...
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, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 2, os dados são lidos diretamente de um componente de IU controlado pelo usuário e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 3, uma fonte fora do aplicativo de destino faz uma solicitação de URL usando o esquema de URL personalizado do aplicativo de destino, e os dados não validados a partir da solicitação de URL subsequentemente são lidos pelo aplicativo como dados confiáveis e incluídos no conteúdo 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 apresentam um comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.eid, de uma solicitação HTTP e o exibe para o usuário.
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
Example 1, esse código funcionará corretamente se eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.Example 1, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.cl_http_utility=>escape_html, impedirá alguns ataques de criação de script entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, & e ", que são codificados em HTML, e aqueles além de <, >, &, " e ', que estão codificados em XML, podem assumir um metassentido. Valer-se desses módulos de função de codificação é equivalente a usar uma lista de bloqueios insuficiente para evitar a criação de script entre sites, podendo permitir que um invasor injete um código mal-intencionado que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados aparecem estaticamente, os rulepacks do Fortify Secure Coding relatam descobertas de criação de script entre sites, mesmo quando a codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.eid, de uma solicitação HTTP, codifica essa ID em HTML e a exibe para o usuário.
...
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 contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.eid, de uma solicitação HTTP, codifica essa ID em HTML e a exibe para o usuário.
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 contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!HTMLENCODE(variable)}'">Click me!</div>
HTMLENCODE, não valida corretamente os dados fornecidos pelo banco de dados e é vulnerável a XSS. Isso acontece porque o conteúdo de variable é analisado por diferentes mecanismos (analisadores de HTML e Javascript) e, portanto, precisa ser codificado duas vezes. Dessa forma, um invasor pode ter comandos mal-intencionados executados no navegador da Web do usuário, sem a necessidade de interagir com a vítima como na XSS Refletida. Esse tipo de ataque, conhecido como XSS Armazenada (ou Persistente), pode ser muito difícil de detectar, pois os dados são indiretamente fornecidos para a função vulnerável e também têm um impacto maior devido à possibilidade de afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.username, e o exibe ao usuário.
<script>
document.write('{!HTMLENCODE($CurrentPage.parameters.username)}')
</script>
username contiver metacaracteres ou código-fonte, ele será executado pelo navegador da Web. Além disso, neste exemplo, o uso de HTMLENCODE não é suficiente para prevenir o ataque de XSS, já que a variável é processada pelo analisador de Javascript.Example 1, o banco de dados ou outro armazenamento de dados pode fornecer dados perigosos ao aplicativo que serão incluídos no conteúdo dinâmico. Do ponto de vista do invasor, o melhor lugar para armazenar conteúdo mal-intencionado é em uma área acessível a todos os usuários, especialmente para aqueles com privilégios elevados, que são mais propensos a lidar com informações confidenciais ou realizar operações críticas.Example 2, os dados são lidos na solicitação HTTP e refletidos de volta na resposta HTTP. A XSS Refletida ocorre quando um invasor pode ter conteúdo perigoso distribuído a um aplicativo Web vulnerável e, em seguida, refletido de volta para o usuário e executado por seu navegador. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é postada publicamente ou enviada por email diretamente para a vítima. As URLs criadas dessa forma são a essência de muitos esquemas de phishing, nos quais o invasor convence a vítima a visitar a URL. Depois que o site refletir o conteúdo de volta para o usuário, ele será executado e poderá realizar várias ações, como encaminhar informações confidenciais particulares, executar operações não autorizadas no computador da vítima, etc.
<script runat="server">
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
...
</script>
Login e EmployeeID são controles de formulário definidos da seguinte maneira:Exemplo 2: O seguinte segmento de código ASP.NET implementa a mesma funcionalidade que o
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 1, ainda que de forma programática.
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
Login contiver apenas texto alfanumérico padrão. Se Login tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta 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 é um controle de formulário definido da seguinte maneira:Exemplo 4: De mesma forma, o seguinte segmento de código ASP.NET é funcionalmente equivalente ao
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 3, mas implementa todos os elementos de formulário programaticamente.
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 e no Example 2, esses segmentos de código são executados corretamente quando os valores de name apresentam um comportamento satisfatório, mas não fazem nada para evitar na ausência desse comportamento. Mais uma vez, esses exemplos de código podem parecer menos perigosos porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1 e no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 3 e no Example 4, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.text de uma solicitação HTTP, codifica esse parâmetro em HTML e o exibe em uma caixa de alerta entre tags de script.
"<script>alert('<CFOUTPUT>HTMLCodeFormat(#Form.text#)</CFOUTPUT>')</script>";
text contiver apenas texto alfanumérico padrão. Se text tiver uma aspa simples, um parêntese e um ponto-e-vírgula, ele terminará a caixa de texto alert e, em seguida, o código será executado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.user, de uma solicitação HTTP e o exibe para o usuário.
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", html.EscapeString(user))
}
user contiver apenas texto alfanumérico padrão. Se user tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque a indireção causada pelo armazenamento de dados dificulta a identificação da ameaça e aumenta a possibilidade de o ataque afetar vários usuários. O XSS começou dessa forma, com sites que ofereciam um "livro de visitas" aos visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações XSS refletidas ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor poderá executar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais pertencentes ao usuário.<c:out/> com o atributo escapeXml="true" (o comportamento padrão), evita alguns ataques de criação de scripts entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, & e ", que são codificados em HTML, e aqueles além de <, >, &, " e ', que estão codificados em XML, poderão assumir um metassentido. Valer-se dessas construções de codificação é equivalente a usar uma lista de bloqueios fraca para evitar a criação de script entre sites, podendo permitir que um invasor injete um código mal-intencionado, que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados são exibidos estaticamente, o Fortify Static Code Analyzer relata descobertas de criação de script entre sites mesmo quando uma codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.eid, de uma solicitação HTTP e a exibe para o usuário por meio da tag <c:out/>.
Employee ID: <c:out value="${param.eid}"/>
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.<c:out/>.
<%...
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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(URLEncoder.encode(url));
...
url começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 3, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.eid, de uma solicitação HTTP, faz o escape dele e o exibe para o usuário.
<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(escape(document.URL.substring(pos,document.URL.length)));
</SCRIPT>
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.<c:out/> com o atributo escapeXml="true" (o comportamento padrão), evita alguns ataques de criação de scripts entre sites, mas nem todos. Dependendo do contexto em que os dados são apresentados, caracteres além dos básicos <, >, & e ", que são codificados em HTML, e aqueles além de <, >, &, " e ', que estão codificados em XML, poderão assumir um metassentido. Valer-se dessas construções de codificação é equivalente a usar uma lista de bloqueios fraca para evitar a criação de script entre sites, podendo permitir que um invasor injete um código mal-intencionado, que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados são exibidos estaticamente, o Fortify Static Code Analyzer relata descobertas de criação de script entre sites mesmo quando uma codificação é aplicada, e as apresenta como Cross-Site Scripting: Validação Insuficiente.eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.
...
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 começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 3, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.myapp://input_to_the_application). Os dados não confiáveis na URL são então utilizados para renderizar a saída HTML em um componente WebView.
...
- (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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Novamente, esse código pode parecer menos perigoso porque o valor name é lido de um banco de dados e é codificado em HTML. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. O ataque feito pelo invasor poderia ignorar os caracteres codificados ou colocar uma entrada em um contexto que não seja afetado pela codificação HTML. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente de um URL de esquema personalizado e refletidos de volta no conteúdo de uma resposta UIWebView. Os ataques de XSS refletido ocorrem quando um invasor faz com que um usuário forneça conteúdo perigoso a um aplicativo iOS vulnerável, o que é então refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a propagação de conteúdo malicioso é incluí-lo como um parâmetro em um URL de esquema personalizado veiculada publicamente ou diretamente por email para as vítimas. As URLs criadas dessa forma constituem o núcleo de muitos esquemas de phishing, em que um invasor convence as vítimas a visitar uma URL que se refere a um aplicativo vulnerável. Depois que o aplicativo reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.htmlspecialchars() ou htmlentities(), impedirá alguns, mas não todos os ataques cross-site scripting. Dependendo do contexto em que os dados são apresentados, os caracteres diferentes dos básicos <, >, & e " que são codificados em HTML, e aqueles além de <, >, &, " e ' (somente quando ENT_QUOTES está definido), que estão codificados em XML podem assumir um metassentido. Valer-se dessas funções de codificação é equivalente a usar uma lista de bloqueios insuficiente para evitar Cross-Site Scripting, podendo permitir que um invasor injete código mal-intencionado que será executado no navegador. Como nem sempre é possível identificar com precisão o contexto em que os dados aparecem estaticamente, os rulepacks do Fortify Secure Coding relatam descobertas de criação de script entre sites, mesmo quando a codificação é aplicada, e as apresenta como problemas de Cross-Site Scripting: Validação Insuficiente.text de uma solicitação HTTP, codifica esse parâmetro em HTML e o exibe em uma caixa de alerta entre tags de script.
<?php
$var=$_GET['text'];
...
$var2=htmlspecialchars($var);
echo "<script>alert('$var2')</script>";
?>
text contiver apenas texto alfanumérico padrão. Se text tiver uma aspa simples, um parêntese e um ponto-e-vírgula, ele terminará a caixa de texto alert e, em seguida, o código será executado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.eid, a partir de uma solicitação HTTP, a codifica em URL, e a exibe ao usuário.
...
-- 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 contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.eid, a partir de uma solicitação HTTP, a codifica em HTML, e a exibe ao usuário.
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + escape(eid))
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + escape(row["emp"]))
...
Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.eid, a partir de uma solicitação HTTP, a codifica em HTML, e a exibe ao usuário.
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.Rack::Request#params() como no Example 1, ele verá os parâmetros GET e POST, então você pode estar vulnerável a vários tipos de outros ataques, e não apenas ter o código malicioso anexado à 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada de todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.eid, de uma solicitação HTTP e o exibe para o usuário.
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 contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.myapp://input_to_the_application). Os dados não confiáveis na URL são então utilizados para renderizar a saída HTML em um componente WebView.
...
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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Novamente, esse código pode parecer menos perigoso porque o valor name é lido de um banco de dados e é codificado em HTML. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. O ataque feito pelo invasor poderia ignorar os caracteres codificados ou colocar uma entrada em um contexto que não seja afetado pela codificação HTML. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField contiver apenas um texto alfanumérico padrão. Se o texto no inputTextField incluir metacaracteres ou código-fonte, a entrada poderá ser executada como código pelo navegador da Web conforme exibe a resposta HTTP.Example 1, os dados são lidos diretamente de um URL de esquema personalizado e refletidos de volta no conteúdo de uma resposta UIWebView. Os ataques de XSS refletido ocorrem quando um invasor faz com que um usuário forneça conteúdo perigoso a um aplicativo iOS vulnerável, o que é então refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a propagação de conteúdo malicioso é incluí-lo como um parâmetro em um URL de esquema personalizado veiculada publicamente ou diretamente por email para as vítimas. As URLs criadas dessa forma constituem o núcleo de muitos esquemas de phishing, em que um invasor convence as vítimas a visitar uma URL que se refere a um aplicativo vulnerável. Depois que o aplicativo reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 3, uma fonte fora do aplicativo de destino faz uma solicitação de URL usando o esquema de URL personalizado do aplicativo de destino, e os dados não validados a partir da solicitação de URL subsequentemente são lidos pelo aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.eid, de uma solicitação HTTP, a codifica em HTML e a exibe para o usuário.
...
eid = Request("eid")
Response.Write "Employee ID:" & Server.HTMLEncode(eid) & "<br/>"
..
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.eid, de uma solicitação HTTP e a exibe para o usuário.
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.eid, de uma solicitação HTTP e a exibe para o usuário.
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 contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.username, e o exibe ao usuário.
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username contiver metacaracteres ou código-fonte, ele será executado pelo navegador da Web.
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
Example 1, esse código se comporta corretamente quando os valores de name estão bem definidos, assim como caracteres alfanuméricos, mas não faz nada para verificar se há dados mal-intencionados. Mesmo lido do banco de dados, o valor deve ser devidamente validado, pois o conteúdo do banco de dados pode ser proveniente de dados fornecidos pelo usuário. Dessa forma, um invasor pode ter comandos mal-intencionados executados no navegador da Web do usuário, sem a necessidade de interagir com a vítima como na XSS Refletida. Esse tipo de ataque, conhecido como XSS Armazenada (ou Persistente), pode ser muito difícil de detectar, pois os dados são indiretamente fornecidos para a função vulnerável e também têm um impacto maior devido à possibilidade de afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos na solicitação HTTP e refletidos de volta na resposta HTTP. A XSS Refletida ocorre quando um invasor pode ter conteúdo perigoso distribuído a um aplicativo Web vulnerável e, em seguida, refletido de volta para o usuário e executado por seu navegador. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é postada publicamente ou enviada por email diretamente para a vítima. As URLs criadas dessa forma são a essência de muitos esquemas de phishing, nos quais o invasor convence a vítima a visitar a URL. Depois que o site refletir o conteúdo de volta para o usuário, ele será executado e poderá realizar várias ações, como encaminhar informações confidenciais particulares, executar operações não autorizadas no computador da vítima, etc.Example 2, o banco de dados ou outro armazenamento de dados pode fornecer dados perigosos ao aplicativo que serão incluídos no conteúdo dinâmico. Do ponto de vista do invasor, o melhor lugar para armazenar conteúdo mal-intencionado é em uma área acessível a todos os usuários, especialmente para aqueles com privilégios elevados, que são mais propensos a lidar com informações confidenciais ou realizar operações críticas.
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Login e EmployeeID são controles de formulário definidos da seguinte maneira:Exemplo 2: O seguinte segmento de código ASP.NET mostra a maneira programática de implementar o
<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 contiver apenas texto alfanumérico padrão. Se Login tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta 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 é um controle de formulário definido da seguinte maneira:Exemplo 4: O seguinte segmento de código ASP.NET é funcionalmente equivalente ao
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 3, mas implementa todos os elementos de formulário programaticamente.
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 e no Example 2, esses exemplos de código funcionam corretamente quando os valores de name apresentam um comportamento satisfatório, mas não fazem nada para evitar na ausência desse comportamento. Mais uma vez, estes podem parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1 e no Example 2, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 3 e no Example 4, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.EID, de um formulário HTML e o exibe para o usuário.
...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.
EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...
EID contiver apenas texto alfanumérico padrão. Se EID tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.
...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.
EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...
Example 1, esse código funciona corretamente quando os valores de ENAME apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de ENAME é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de ENAME for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Armazenado, é especialmente insidioso porque o engano causado pelo armazenamento de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque afete vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente no Formulário HTML e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS armazenadas ocorrem quando um invasor eid, de um formulário da Web e a exibe para o usuário.
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Form.eid contiver apenas texto alfanumérico padrão. Se Form.eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta HTTP.
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>
Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.user, de uma solicitação HTTP e o exibe para o usuário.
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}
user contiver apenas texto alfanumérico padrão. Se user tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web conforme este exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque a indireção causada pelo armazenamento de dados dificulta a identificação da ameaça e aumenta a possibilidade de o ataque afetar vários usuários. O XSS começou dessa forma, com sites que ofereciam um "livro de visitas" aos visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações XSS refletidas ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor poderá executar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais pertencentes ao usuário.eid, de uma solicitação HTTP e a exibe para o usuário.
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...
url começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 3, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.eid, a partir de uma solicitação HTTP e a exibe ao usuário.
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 contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.eid, de uma solicitação de servlet HTTP e, em seguida, exibe o valor de volta para o usuário na resposta do servlet.
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...
url começar com javascript:, o código JavaScript seguinte será executado no contexto da página da Web dentro de WebView.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Example 3, uma fonte externa ao aplicativo armazena dados perigosos em um banco de dados ou outro repositório de dados, e esses dados perigosos são posteriormente lidos de volta para o aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.myapp://input_to_the_application). Os dados não confiáveis na URL são então utilizados para renderizar a saída HTML em um componente WebView.
- (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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente de um URL de esquema personalizado e refletidos de volta no conteúdo de uma resposta UIWebView. Os ataques de XSS refletido ocorrem quando um invasor faz com que um usuário forneça conteúdo perigoso a um aplicativo iOS vulnerável, o que é então refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a propagação de conteúdo malicioso é incluí-lo como um parâmetro em um URL de esquema personalizado veiculada publicamente ou diretamente por email para as vítimas. As URLs criadas dessa forma constituem o núcleo de muitos esquemas de phishing, em que um invasor convence as vítimas a visitar uma URL que se refere a um aplicativo vulnerável. Depois que o aplicativo reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.eid, de uma solicitação HTTP e a exibe para o usuário.
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.eid, a partir de uma solicitação HTTP e a exibe ao usuário.
...
-- 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 contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.eid, a partir de uma solicitação HTTP e a exibe ao usuário.
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...
Example 1, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.eid, a partir de uma solicitação HTTP e a exibe ao usuário.
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.Rack::Request#params() como no Example 1, ele verá os parâmetros GET e POST, então você pode estar vulnerável a vários tipos de outros ataques, e não apenas ter o código malicioso anexado à 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.eid, de uma solicitação HTTP e a exibe para o usuário.
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 contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta HTTP.
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField contiver apenas um texto alfanumérico padrão. Se o texto no inputTextField incluir metacaracteres ou código-fonte, a entrada poderá ser executada como código pelo navegador da Web conforme exibe a resposta HTTP.myapp://input_to_the_application). Os dados não confiáveis na URL são então utilizados para renderizar a saída HTML em um componente WebView.
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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente de um componente de IU controlado pelo usuário e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, uma fonte fora do aplicativo de destino faz uma solicitação de URL usando o esquema de URL personalizado do aplicativo de destino, e os dados não validados a partir da solicitação de URL subsequentemente são lidos pelo aplicativo como dados confiáveis e incluídos no conteúdo dinâmico.Example 3, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.eid, de uma solicitação HTTP e o exibe para o usuário.
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
eid contiver apenas texto alfanumérico padrão. Se eid tiver um valor que inclui metacaracteres ou código-fonte, o código será executado pelo navegador da Web quando ele exibir a resposta 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, esse código funciona corretamente quando os valores de name apresentam comportamento satisfatório, mas não faz nada para evitar explorações na ausência desse comportamento. Mais uma vez, esse código pode parecer menos perigoso porque o valor de name é lido de um banco de dados, cujo conteúdo é aparentemente gerenciado pelo aplicativo. No entanto, se o valor de name for proveniente de dados fornecidos pelo usuário, o banco de dados poderá ser um canal de conteúdo mal-intencionado. Sem a devida validação de entrada em todos os dados armazenados no banco de dados, um invasor pode executar comandos mal-intencionados no navegador da Web do usuário. Esse tipo de exploração, conhecido como XSS Persistente (ou Armazenado), é particularmente traiçoeiro porque o desvio causado pelo repositório de dados dificulta a identificação da ameaça e aumenta a possibilidade de que o ataque possa afetar vários usuários. A XSS teve seu início dessa maneira, com sites que ofereciam um "livro de visitas" para os visitantes. Os invasores poderiam incluir JavaScript em suas entradas no livro de visitas, e todos os visitantes subsequentes desse livro executariam o código mal-intencionado.Example 1, os dados são lidos diretamente na solicitação HTTP e refletidos de volta na resposta HTTP. As explorações de XSS Refletida ocorrem quando um invasor induz o usuário a fornecer conteúdo perigoso a um aplicativo da Web vulnerável, que é refletido de volta ao usuário e executado pelo navegador da Web. O mecanismo mais comum para a distribuição de conteúdo mal-intencionado é incluí-lo como um parâmetro em uma URL que é veiculada publicamente ou enviada por email diretamente para as vítimas. As URLs construídas dessa maneira constituem o núcleo de muitos esquemas de phishing, de acordo com os quais um invasor convence as vítimas a visitarem uma URL que as direciona para um site vulnerável. Depois que o site reflete o conteúdo do invasor de volta ao usuário, o conteúdo é executado e passa a transferir informações privadas, como cookies que podem incluir informações da sessão, do computador do usuário para o invasor ou executar outras atividades nefastas.Example 2, o aplicativo armazena dados perigosos em um banco de dados ou em outro repositório de dados confiável. Esses dados perigosos são posteriormente lidos de volta para o aplicativo e incluídos no conteúdo dinâmico. Explorações de XSS Persistente ocorrem quando um invasor injeta em um repositório de dados um conteúdo perigoso que, mais tarde, é lido e incluído no conteúdo dinâmico. Na perspectiva de um invasor, o lugar ideal para injetar o conteúdo mal-intencionado é em uma área que é exibida para muitos usuários ou para usuários de interesse particular. Esses usuários de interesse normalmente têm privilégios elevados no aplicativo ou interagem com dados confidenciais que são valiosos para o invasor. Se um desses usuários executar conteúdo mal-intencionado, o invasor talvez seja capaz de realizar operações privilegiadas em nome do usuário ou obter acesso a dados confidenciais que pertencem a ele.Origin, ele permitirá que qualquer site mal-intencionado represente o usuário e estabeleça uma conexão WebSocket bidirecional sem o usuário sequer perceber.Origin, ele permitirá que qualquer site mal-intencionado represente o usuário e estabeleça uma conexão WebSocket bidirecional sem o usuário sequer perceber.