sprintf()
, FormatMessageW()
ou syslog()
.snprintf()
.
int main(int argc, char **argv){
char buf[128];
...
snprintf(buf,128,argv[1]);
}
%x
, do que a função utiliza como argumentos a serem formatados. (Neste exemplo, a função não usa argumentos a serem formatados.) Ao usar a diretiva de formatação %n
, o invasor pode gravar na pilha, fazendo com que snprintf()
grave no argumento especificado o número de bytes cuja saída foi processada até o momento (em vez de ler um valor do argumento, que é o comportamento pretendido). Uma versão sofisticada desse ataque usará quatro gravações escalonadas para controlar completamente o valor de um apontador na pilha.
printf("%d %d %1$d %1$d\n", 5, 9);
5 9 5 5
Example 1
.syslog()
por vezes utilizada da seguinte maneira:
...
syslog(LOG_ERR, cmdBuf);
...
syslog()
é uma string de formato, qualquer diretiva de formatação incluída em cmdBuf
é interpretada conforme descrito no Example 1
.syslog()
:
...
syslog(LOG_ERR, "%s", cmdBuf);
...
sprintf()
, FormatMessageW()
, syslog()
, NSLog
, ou NSString.stringWithFormat
como um argumento do formato StringNSString.stringWithFormat:
.
int main(int argc, char **argv){
char buf[128];
...
[NSString stringWithFormat:argv[1], argv[2] ];
}
%x
, do que a função utiliza como argumentos a serem formatados. (Neste exemplo, a função não usa argumentos a serem formatados.)
printf("%d %d %1$d %1$d\n", 5, 9);
5 9 5 5
Example 1
.syslog()
por vezes utilizada da seguinte maneira:
...
syslog(LOG_ERR, cmdBuf);
...
syslog()
é uma string de formato, qualquer diretiva de formatação incluída em cmdBuf
é interpretada conforme descrito no Example 1
.syslog()
:Exemplo 4: As classes principais da Apple proporcionam rotas interessantes para explorar as vulnerabilidades do formato String.
...
syslog(LOG_ERR, "%s", cmdBuf);
...
String.stringByAppendingFormat()
por vezes utilizada da seguinte maneira:
...
NSString test = @"Sample Text.";
test = [test stringByAppendingFormat:[MyClass
formatInput:inputControl.text]];
...
stringByAppendingFormat()
:
...
NSString test = @"Sample Text.";
test = [test stringByAppendingFormat:@"%@", [MyClass
formatInput:inputControl.text]];
...
strncpy()
, podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.
void wrongNumberArgs(char *s, float f, int d) {
char buf[1024];
sprintf(buf, "Wrong number of %.512s");
}
strncpy()
, podem causar vulnerabilidades quando usadas incorretamente. A combinação entre manipulação de memória e suposições equivocadas sobre o tamanho ou a composição de um determinado dado é a causa raiz da maioria dos estouros de buffer.f
de um flutuante usando um especificador de formato %d
.
void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
char buf[1024];
sprintf(buf, "Wrong type of %d", f);
...
}
author
, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.
...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.
@HttpGet
global static void doGet() {
...
Map<String, String> params = ApexPages.currentPage().getParameters();
RestResponse res = RestContext.response;
res.addHeader(params.get('name'), params.get('value'));
...
}
author
e Jane Smith
, a resposta HTTP incluindo este cabeçalho pode ter o seguinte formato:
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo
e bar
, e a resposta HTTP seria dividida em duas respostas da seguinte forma:
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
HttpResponse.AddHeader()
. Se você estiver usando o .NET Framework mais recente que impede a definição de cabeçalhos com caracteres de nova linha, talvez o seu aplicativo não seja vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.author
, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.
protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
Author.Text
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
author
, de um formulário HTML e o define no cabeçalho de um cookie de uma resposta HTTP.
...
EXEC CICS
WEB READ
FORMFIELD(NAME)
VALUE(AUTHOR)
...
END-EXEC.
EXEC CICS
WEB WRITE
HTTPHEADER(COOKIE)
VALUE(AUTHOR)
...
END-EXEC.
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.author
, a partir de um formulário da Web e o define em um cabeçalho de cookie de uma resposta HTTP.
<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1/1 200 OK
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.
final server = await HttpServer.bind('localhost', 18081);
server.listen((request) async {
final headers = request.headers;
final contentType = headers.value('content-type');
final client = HttpClient();
final clientRequest = await client.getUrl(Uri.parse('https://example.com'));
clientRequest.headers.add('Content-Type', contentType as Object);
});
author
, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.
...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.author
, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
author
, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.
author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.name
e value
podem ser controlados por um invasor. O código define um cabeçalho HTTP cujo nome e valor podem ser controlados por um invasor:
...
NSURLSessionConfiguration * config = [[NSURLSessionConfiguration alloc] init];
NSMutableDictionary *dict = @{};
[dict setObject:value forKey:name];
[config setHTTPAdditionalHeaders:dict];
...
author
e Jane Smith
, a resposta HTTP que inclui esse cabeçalho pode ter o seguinte formato:
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo
e bar
, e a resposta HTTP seria dividida em duas respostas no seguinte formato:
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
header()
. Se a sua versão de PHP impedir a definição de cabeçalhos com novos caracteres de linha, seu aplicativo não estará vulnerável à Divisão de resposta HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.
<?php
$location = $_GET['some_location'];
...
header("location: $location");
?>
HTTP/1.1 200 OK
...
location: index.html
...
some_location
não tiver nenhum caractere CR e LF. Se um invasor enviar uma cadeia de caracteres mal-intencionada, como "index.html\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas da seguinte forma:
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
author
, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.
...
-- Assume QUERY_STRING looks like AUTHOR_PARAM=Name
author := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 14);
OWA_UTIL.mime_header('text/html', false);
OWA_COOKE.send('author', author);
OWA_UTIL.http_header_close;
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
location = req.field('some_location')
...
response.addHeader("location",location)
HTTP/1.1 200 OK
...
location: index.html
...
some_location
não tiver nenhum caractere CR e LF. Se um invasor enviar uma cadeia de caracteres mal-intencionada, como "index.html\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas da seguinte forma:
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.author
, a partir de uma solicitação HTTP e o usa em uma solicitação GET em outra parte do site.
author = req.params[AUTHOR_PARAM]
http = Net::HTTP.new(URI("http://www.mysite.com"))
http.post('/index.php', "author=#{author}")
POST /index.php HTTP/1.1
Host: www.mysite.com
author=Jane Smith
...
AUTHOR_PARAM
não contiver quaisquer caracteres CR e LF. Se um invasor enviar uma cadeia maliciosa, como "Wiley Hacker\r\nPOST /index.php HTTP/1.1\r\n...", então a resposta HTTP seria dividida em duas respostas neste formato:
POST /index.php HTTP/1.1
Host: www.mysite.com
author=Wiley Hacker
POST /index.php HTTP/1.1
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.name
e value
podem ser controlados por um invasor. O código define um cabeçalho HTTP cujo nome e valor podem ser controlados por um invasor:
...
var headers = []
headers[name] = value
let config = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier("com.acme")
config.HTTPAdditionalHeaders = headers
...
author
e Jane Smith
, a resposta HTTP que inclui esse cabeçalho pode ter o seguinte formato:
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo
e bar
, e a resposta HTTP seria dividida em duas respostas no seguinte formato:
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
author
, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.
...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.author
, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.
...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.author
, de uma solicitação HTTP, e o define em um cabeçalho de cookie de uma resposta HTTP.
...
Cookie cookie = new Cookie('author', author, '/', -1, false);
ApexPages.currentPage().setCookies(new Cookie[] {cookie});
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
author
não contiver caracteres de CR e LF. Se um invasor enviar uma cadeia de caracteres mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.author
, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.
protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.author
, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.
<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.author
, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.
...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
não contiver caracteres de CR e LF. Se um invasor enviar uma cadeia de caracteres mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.author
, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
Example 1
à plataforma Android.Desfiguração entre Usuários: Um invasor poderá fazer uma única solicitação a um servidor vulnerável, fazendo com que esse servidor crie duas respostas. A segunda pode ser interpretada como uma resposta a uma solicitação diferente, possivelmente feita por outro usuário que compartilha a mesma conexão TCP com o servidor. Isso pode ser feito, convencendo o usuário a enviar a solicitação mal-intencionada por conta própria ou remotamente em situações nas quais o invasor e o usuário compartilham uma conexão TCP comum com o servidor, como um servidor proxy compartilhado. Na melhor das hipóteses, um invasor pode aproveitar essa habilidade para convencer os usuários de que o aplicativo foi invadido, fazendo com que eles percam a confiança na segurança deste último. Na pior das hipóteses, um invasor pode fornecer um conteúdo especialmente elaborado, projetado para imitar o comportamento do aplicativo, mas redirecionar informações privadas, como números de contas e senhas, de volta para ele.
...
CookieManager webCookieManager = CookieManager.getInstance();
String author = this.getIntent().getExtras().getString(AUTHOR_PARAM);
String setCookie = "author=" + author + "; max-age=" + cookieExpiration;
webCookieManager.setCookie(url, setCookie);
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.author
, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.
author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.author
, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.
<?php
$author = $_GET['AUTHOR_PARAM'];
...
header("author: $author");
?>
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
location = req.field('some_location')
...
response.addHeader("location",location)
HTTP/1.1 200 OK
...
location: index.html
...
some_location
não tiver nenhum caractere CR e LF. Se um invasor enviar uma cadeia de caracteres mal-intencionada, como "index.html\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas da seguinte forma:
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impedir a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não será vulnerável à HTTP Response Splitting. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Cookie Manipulation ou Open Redirects e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.IllegalArgumentException
se você tentar definir um cabeçalho com caracteres proibidos. Se o seu servidor de aplicativos impede a definição de cabeçalhos com caracteres de nova linha, seu aplicativo não é vulnerável à Divisão de Respostas HTTP. No entanto, uma simples filtragem em busca de caracteres de nova linha pode deixar um aplicativo vulnerável à Manipulação de Cookie ou a Redirecionamentos Abertos e, por isso, ainda é necessário ter cautela ao definir cabeçalhos HTTP com entradas do usuário.author
, a partir de uma solicitação HTTP e o define em um cabeçalho de cookie de uma resposta HTTP.
...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", a resposta HTTP será dividida em duas respostas com o seguinte formato:
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
CC
ou BCC
, que eles podem usar para vazar o conteúdo do e-mail para eles mesmos ou usar o servidor de correio como um bot de spam.CC
com uma lista de endereços de e-mail para distribuição anônima como spam, já que o e-mail será enviado a partir do servidor da vítima.
func handler(w http.ResponseWriter, r *http.Request) {
subject := r.FormValue("subject")
body := r.FormValue("body")
auth := smtp.PlainAuth("identity", "user@example.com", "password", "mail.example.com")
to := []string{"recipient@example.net"}
msg := []byte("To: " + recipient1 + "\r\n" + subject + "\r\n" + body + "\r\n")
err := smtp.SendMail("mail.example.com:25", auth, "sender@example.org", to, msg)
if err != nil {
log.Fatal(err)
}
}
...
subject: [Contact us query] Page not working
...
subject
não contiver caracteres de CR e LF. Se um invasor enviar uma string mal-intencionada, como "Parabéns!! Você ganhou na loteria!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", os cabeçalhos SMTP serão:
...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...
CC
ou BCC
, que eles podem usar para deixar vazar o conteúdo de e-mails para si ou que podem usar o servidor de e-mail como um robô de spam.CC
com uma lista de endereços de e-mail para distribuição anônima como spam, já que o e-mail será enviado a partir do servidor da vítima.
String subject = request.getParameter("subject");
String body = request.getParameter("body");
MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress("webform@acme.com"));
message.setRecipients(Message.RecipientType.TO, InternetAddress.parse("support@acme.com"));
message.setSubject("[Contact us query] " + subject);
message.setText(body);
Transport.send(message);
...
subject: [Contact us query] Page not working
...
subject
não contiver caracteres de CR e LF. Se um invasor enviasse uma string mal-intencionada, como "Parabéns!!! Você ganhou na loteria!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", os cabeçalhos SMTP teriam o seguinte formato:
...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...
CC
ou BCC
, que eles podem usar para deixar vazar o conteúdo de e-mails para si ou que podem usar o servidor de e-mail como um robô de spam.CC
com uma lista de endereços de e-mail para distribuição anônima como spam, já que o e-mail será enviado a partir do servidor da vítima.
$subject = $_GET['subject'];
$body = $_GET['body'];
mail("support@acme.com", "[Contact us query] " . $subject, $body);
...
subject: [Contact us query] Page not working
...
subject
não contiver caracteres de CR e LF. Se um invasor enviasse uma string mal-intencionada, como "Parabéns!!! Você ganhou na loteria!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", os cabeçalhos SMTP teriam o seguinte formato:
...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...
CC
ou BCC
, que eles podem usar para deixar vazar o conteúdo de e-mails para si ou que podem usar o servidor de e-mail como um robô de spam.CC
com uma lista de endereços de e-mail para distribuição anônima como spam, já que o e-mail será enviado a partir do servidor da vítima.
body = request.GET['body']
subject = request.GET['subject']
session = smtplib.SMTP(smtp_server, smtp_tls_port)
session.ehlo()
session.starttls()
session.login(username, password)
headers = "\r\n".join(["from: webform@acme.com",
"subject: [Contact us query] " + subject,
"to: support@acme.com",
"mime-version: 1.0",
"content-type: text/html"])
content = headers + "\r\n\r\n" + body
session.sendmail("webform@acme.com", "support@acme.com", content)
...
subject: [Contact us query] Page not working
...
subject
não contiver caracteres de CR e LF. Se um invasor enviasse uma string mal-intencionada, como "Parabéns!!! Você ganhou na loteria!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", os cabeçalhos SMTP teriam o seguinte formato:
...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...
allowBackup
como true
(o valor padrão) e definindo o atributo backupAgent
na tag do <application>
.Environment.getExternalStorageDirectory()
retorna uma referência ao armazenamento externo do dispositivo Android.private void WriteToFile(String what_to_write) {
try{
File root = Environment.getExternalStorageDirectory();
if(root.canWrite()) {
File dir = new File(root + "write_to_the_SDcard");
File datafile = new File(dir, number + ".extension");
FileWriter datawriter = new FileWriter(datafile);
BufferedWriter out = new BufferedWriter(datawriter);
out.write(what_to_write);
out.close();
}
}
}
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
:kSecAttrAccessibleAlways
:kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
:kSecAttrAccessibleAlwaysThisDeviceOnly
:kSecAttrAccessibleWhenUnlocked
:kSecAttrAccessibleWhenUnlockedThisDeviceOnly
:ThisDeviceOnly
serão armazenados em backup no iCloud e no iTunes, mesmo se você estiver usando backups não criptografados que podem ser restaurados para qualquer dispositivo. Dependendo de quão confidenciais e privados os dados armazenados são, isso pode gerar uma preocupação de privacidade.
...
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];
// Configure KeyChain Item
[dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
[dict setObject:token forKey:(__bridge id)kSecValueData];
...
[dict setObject:(__bridge id)kSecAttrAccessibleWhenUnlocked forKey:(__bridge id) kSecAttrAccessible];
OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
:kSecAttrAccessibleAlways
:kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
:kSecAttrAccessibleAlwaysThisDeviceOnly
:kSecAttrAccessibleWhenUnlocked
:kSecAttrAccessibleWhenUnlockedThisDeviceOnly
:ThisDeviceOnly
serão armazenados em backup no iCloud e no iTunes, mesmo se você estiver usando backups não criptografados que podem ser restaurados para qualquer dispositivo. Dependendo de quão confidenciais e privados os dados armazenados são, isso pode gerar uma preocupação de privacidade.
...
// Configure KeyChain Item
let token = "secret"
var query = [String : AnyObject]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecValueData as String] = token as AnyObject?
...
query[kSecAttrAccessible as String] = kSecAttrAccessibleWhenUnlocked
SecItemAdd(query as CFDictionary, nil)
...
protected void onCreate(Bundle savedInstanceState) {
...
try {
File httpCacheDir = new File(context.getExternalCacheDir(), "http");
long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
HttpResponseCache.install(httpCacheDir, httpCacheSize);
} catch (IOException e) {
Log.i(TAG, "HTTP response cache installation failed:" + e);
}
}
protected void onStop() {
...
HttpResponseCache cache = HttpResponseCache.getInstalled();
if (cache != null) {
cache.flush();
}
}
{app ID}/Library/Caches/com.mycompany.myapp/Cache.db*
.{app ID}/Library/Caches/com.mycompany.myapp/Cache.db*
.{app ID}/Library/Caches/com.mycompany.myapp/Cache.db*
. diskCapacity
ou memoryCapacity
da classe URLCache
como 0, eles podem estar desabilitando efetivamente o sistema de cache de respostas HTTP(S). No entanto, a documentação de NSURLCache
indica que os caches no disco e na memória serão truncados para os tamanhos configurados somente se o dispositivo estiver sendo executado com pouca memória ou pouco espaço em disco. Ambas as configurações são usadas pelo sistema para liberar recursos do sistema e melhorar o desempenho, não como um controle de segurança.{app ID}/Library/Caches/com.mycompany.myapp/Cache.db*
. diskCapacity
ou memoryCapacity
da classe URLCache
como 0, eles podem estar desabilitando efetivamente o sistema de cache de respostas HTTP(S). No entanto, a documentação de NSURLCache
indica que os caches no disco e na memória serão truncados para os tamanhos configurados somente se o dispositivo estiver sendo executado com pouca memória ou pouco espaço em disco. Ambas as configurações são usadas pelo sistema para liberar recursos do sistema e melhorar o desempenho, não como um controle de segurança.NSFileManager
como constantes que devem ser atribuídas como o valor da chave NSFileProtectionKey
em um NSDictionary
associado à instância do NSFileManager
, e os arquivos podem ser criados ou a classe de proteção de dados deles pode ser modificada por meio da utilização das funções do NSFileManager
, incluindo setAttributes:ofItemAtPath:error:
, attributesOfItemAtPath:error:
e createFileAtPath:contents:attributes:
. Além disso, as constantes correspondentes de Proteção de dados são definidas para objetos NSData
como NSDataWritingOptions
que podem ser transmitidas como o argumento options
para as funções NSData
writeToURL:options:error:
e writeToFile:options:error:
. As definições para as diversas constantes de classe de Proteção de dados do NSFileManager
e do NSData
são as seguintes:NSFileProtectionComplete
, NSDataWritingFileProtectionComplete
:NSFileProtectionCompleteUnlessOpen
, NSDataWritingFileProtectionCompleteUnlessOpen
:NSFileProtectionCompleteUntilFirstUserAuthentication
, NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication
:NSFileProtectionNone
, NSDataWritingFileProtectionNone
:NSFileProtectionCompleteUnlessOpen
ou NSFileProtectionCompleteUntilFirstUserAuthentication
garantirá a encriptação deles por meio de uma chave derivada da senha do usuário e do UID do dispositivo, os dados ainda permanecerão acessíveis sob certas circunstâncias. Como tal, os usos de NSFileProtectionCompleteUnlessOpen
ou NSFileProtectionCompleteUntilFirstUserAuthentication
devem ser estudados cautelosamente para determinar se uma proteção aprofundada com o NSFileProtectionComplete
é garantida.Exemplo 2: Neste exemplo, os dados só estão protegidos até que o usuário ligue o dispositivo e digite a senha pela primeira vez (até a próxima reinicialização):
...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSDictionary *protection = [NSDictionary dictionaryWithObject:NSFileProtectionCompleteUntilFirstUserAuthentication forKey:NSFileProtectionKey];
...
[[NSFileManager defaultManager] setAttributes:protection ofItemAtPath:filepath error:nil];
...
BOOL ok = [testToWrite writeToFile:filepath atomically:YES encoding:NSUnicodeStringEncoding error:&err];
...
...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSData *textData = [textToWrite dataUsingEncoding:NSUnicodeStingEncoding];
...
BOOL ok = [textData writeToFile:filepath options:NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication error:&err];
...
NSFileManager
como constantes que devem ser atribuídas como o valor da chave NSFileProtectionKey
em um Dictionary
associado à instância do NSFileManager
, e os arquivos podem ser criados ou a classe de proteção de dados deles pode ser modificada por meio da utilização das funções NSFileManager
, incluindo setAttributes(_:ofItemAtPath:)
, attributesOfItemAtPath(_:)
e createFileAtPath(_:contents:attributes:)
. Além disso, as constantes correspondentes de Proteção de dados são definidas para objetos NSData
na enumeração NSDataWritingOptions
que podem ser transmitidas como o argumento options
para as funções NSData
writeToFile(_:options:)
. As definições para as diversas constantes de classe de Proteção de dados do NSFileManager
e do NSData
são as seguintes:NSFileProtectionComplete
, NSDataWritingOptions.DataWritingFileProtectionComplete
:NSFileProtectionCompleteUnlessOpen
, NSDataWritingOptions.DataWritingFileProtectionCompleteUnlessOpen
:NSFileProtectionCompleteUntilFirstUserAuthentication
, NSDataWritingOptions.DataWritingFileProtectionCompleteUntilFirstUserAuthentication
:NSFileProtectionNone
, NSDataWritingOptions.DataWritingFileProtectionNone
:NSFileProtectionCompleteUnlessOpen
ou NSFileProtectionCompleteUntilFirstUserAuthentication
garantirá a encriptação deles por meio de uma chave derivada da senha do usuário e do UID do dispositivo, os dados ainda permanecerão acessíveis sob certas circunstâncias. Como tal, os usos de NSFileProtectionCompleteUnlessOpen
ou NSFileProtectionCompleteUntilFirstUserAuthentication
devem ser estudados cautelosamente para determinar se uma proteção aprofundada com o NSFileProtectionComplete
é garantida.Exemplo 2: Neste exemplo, os dados só estão protegidos até que o usuário ligue o dispositivo e digite a senha pela primeira vez (até a próxima reinicialização):
...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
let protection = [NSFileProtectionKey: NSFileProtectionCompleteUntilFirstUserAuthentication]
do {
try NSFileManager.defaultManager().setAttributes(protection, ofItemAtPath: filename)
} catch let error as NSError {
NSLog("Unable to change attributes: \(error.debugDescription)")
}
...
BOOL ok = textToWrite.writeToFile(filename, atomically:true)
...
...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
...
BOOL ok = textData.writeToFile(filepath, options: .DataWritingFileProtectionCompleteUntilFirstUserAuthentication);
...
kSecAttrAccessible
no dicionário de atributos do conjunto de chaves. As definições das diversas constantes de acessibilidade do conjunto de chaves são as seguintes:kSecAttrAccessibleAfterFirstUnlock
:kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
:kSecAttrAccessibleAlways
:kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
:kSecAttrAccessibleAlwaysThisDeviceOnly
:kSecAttrAccessibleWhenUnlocked
:kSecAttrAccessibleWhenUnlockedThisDeviceOnly
:kSecAttrAccessibleAfterFirstUnlock
garantirá criptografá-lo por meio de uma chave derivada da senha do usuário e do UID do dispositivo, os dados ainda permanecerão acessíveis sob certas circunstâncias. Como tal, os usos de kSecAttrAccessibleAfterFirstUnlock
devem ser estudados cautelosamente para determinar se uma proteção aprofundada é garantida.
...
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];
// Configure KeyChain Item
[dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
[dict setObject:token forKey:(__bridge id)kSecValueData];
...
[dict setObject:(__bridge id)kSecAttrAccessibleAfterFirstUnlock forKey:(__bridge id) kSecAttrAccessible];
OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...
kSecAttrAccessible
no dicionário de atributos do conjunto de chaves. As definições das diversas constantes de acessibilidade do conjunto de chaves são as seguintes:kSecAttrAccessibleAfterFirstUnlock
:kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
:kSecAttrAccessibleAlways
:kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
:kSecAttrAccessibleAlwaysThisDeviceOnly
:kSecAttrAccessibleWhenUnlocked
:kSecAttrAccessibleWhenUnlockedThisDeviceOnly
:kSecAttrAccessibleAfterFirstUnlock
garantirá criptografá-lo por meio de uma chave derivada da senha do usuário e do UID do dispositivo, os dados ainda permanecerão acessíveis sob certas circunstâncias. Como tal, os usos de kSecAttrAccessibleAfterFirstUnlock
devem ser estudados cautelosamente para determinar se uma proteção aprofundada é garantida.
...
// Configure KeyChain Item
let token = "secret"
var query = [String : AnyObject]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecValueData as String] = token as AnyObject?
...
query[kSecAttrAccessible as String] = kSecAttrAccessibleAfterFirstUnlock
SecItemAdd(query as CFDictionary, nil)
...
NSFileManager
como constantes que devem ser atribuídas como o valor da chave NSFileProtectionKey
em um NSDictionary
associado à instância do NSFileManager
, e os arquivos podem ser criados ou a classe de proteção de dados deles pode ser modificada por meio da utilização das funções do NSFileManager
, incluindo setAttributes:ofItemAtPath:error:
, attributesOfItemAtPath:error:
e createFileAtPath:contents:attributes:
. Além disso, as constantes correspondentes de Proteção de dados são definidas para objetos NSData
como NSDataWritingOptions
que podem ser transmitidas como o argumento options
para as funções NSData
writeToURL:options:error:
e writeToFile:options:error:
. As definições para as diversas constantes de classe de Proteção de dados do NSFileManager
e do NSData
são as seguintes:NSFileProtectionComplete
, NSDataWritingFileProtectionComplete
:NSFileProtectionCompleteUnlessOpen
, NSDataWritingFileProtectionCompleteUnlessOpen
:NSFileProtectionCompleteUntilFirstUserAuthentication
, NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication
:NSFileProtectionNone
, NSDataWritingFileProtectionNone
:NSFileProtectionNone
na criptografia utilizando uma chave derivada unicamente baseada no UID do dispositivo. Isso faz com que esses arquivos sejam acessíveis a qualquer momento em que o dispositivo estiver ligado, mesmo quando está iniciando ou bloqueado com uma senha. Como tal, os usos da NSFileProtectionNone
devem ser estudados cautelosamente para determinar se uma proteção aprofundada com uma classe mais rigorosa de Proteção de dados é garantida.Exemplo 2: Neste exemplo, os dados não estão protegidos (são acessíveis a qualquer momento em que o dispositivo estiver ligado):
...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSDictionary *protection = [NSDictionary dictionaryWithObject:NSFileProtectionNone forKey:NSFileProtectionKey];
...
[[NSFileManager defaultManager] setAttributes:protection ofItemAtPath:filepath error:nil];
...
BOOL ok = [testToWrite writeToFile:filepath atomically:YES encoding:NSUnicodeStringEncoding error:&err];
...
...
filepath = [self.GetDocumentDirectory stringByAppendingPathComponent:self.setFilename];
...
NSData *textData = [textToWrite dataUsingEncoding:NSUnicodeStingEncoding];
...
BOOL ok = [textData writeToFile:filepath options:NSDataWritingFileProtectionNone error:&err];
...
NSFileManager
como constantes que devem ser atribuídas como o valor da chave NSFileProtectionKey
em um Dictionary
associado à instância do NSFileManager
. Os arquivos podem ser criados ou a classe de proteção de dados deles pode ser modificada por meio da utilização das funções do NSFileManager
, incluindo setAttributes(_:ofItemAtPath:)
, attributesOfItemAtPath(_:)
e createFileAtPath(_:contents:attributes:)
. Além disso, as constantes correspondentes de Proteção de dados são definidas para objetos NSData
na enumeração NSDataWritingOptions
que podem ser transmitidas como o argumento options
para as funções NSData
como
writeToFile(_:options:)
. As definições para as diversas constantes de classe de Proteção de dados do NSFileManager
e do NSData
são as seguintes:NSFileProtectionComplete
, NSDataWritingOptions.DataWritingFileProtectionComplete
:NSFileProtectionCompleteUnlessOpen
, NSDataWritingOptions.DataWritingFileProtectionCompleteUnlessOpen
:NSFileProtectionCompleteUntilFirstUserAuthentication
, NSDataWritingOptions.DataWritingFileProtectionCompleteUntilFirstUserAuthentication
:NSFileProtectionNone
, NSDataWritingOptions.DataWritingFileProtectionNone
:NSFileProtectionNone
na criptografia utilizando uma chave derivada unicamente baseada no UID do dispositivo. Isso faz com que esses arquivos sejam acessíveis a qualquer momento em que o dispositivo estiver ligado, mesmo quando está iniciando ou bloqueado com uma senha. Como tal, os usos da NSFileProtectionNone
devem ser estudados cautelosamente para determinar se uma proteção aprofundada com uma classe mais rigorosa de Proteção de dados é garantida.Exemplo 2: Neste exemplo, os dados não estão protegidos (são acessíveis a qualquer momento em que o dispositivo estiver ligado):
...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
let protection = [NSFileProtectionKey: NSFileProtectionNone]
do {
try NSFileManager.defaultManager().setAttributes(protection, ofItemAtPath: filename)
} catch let error as NSError {
NSLog("Unable to change attributes: \(error.debugDescription)")
}
...
BOOL ok = textToWrite.writeToFile(filename, atomically:true)
...
...
let documentsPath = NSURL(fileURLWithPath: NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0])
let filename = "\(documentsPath)/tmp_activeTrans.txt"
...
BOOL ok = textData.writeToFile(filepath, options: .DataWritingFileProtectionNone);
...
kSecAttrAccessible
no dicionário de atributos do conjunto de chaves. As definições das diversas constantes de acessibilidade do conjunto de chaves são as seguintes:kSecAttrAccessibleAfterFirstUnlock
:kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
:kSecAttrAccessibleAlways
:kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
:kSecAttrAccessibleAlwaysThisDeviceOnly
:kSecAttrAccessibleWhenUnlocked
:kSecAttrAccessibleWhenUnlockedThisDeviceOnly
:kSecAttrAccessibleAlways
resulta no uso de uma chave derivada unicamente baseada no UID do dispositivo pela criptografia. Isso faz com que esses arquivos sejam acessíveis a qualquer momento em que o dispositivo estiver ligado, mesmo quando está iniciando ou bloqueado com uma senha. Como tal, os usos de kSecAttrAccessibleAlways
deverão ser estudados cautelosamente para determinar se uma proteção aprofundada com um nível de acessibilidade de conjunto de chaves mais rigoroso é garantida.
...
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];
// Configure KeyChain Item
[dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
[dict setObject:token forKey:(__bridge id)kSecValueData];
...
[dict setObject:(__bridge id)kSecAttrAccessibleAlways forKey:(__bridge id) kSecAttrAccessible];
OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...
kSecAttrAccessible
no dicionário de atributos do conjunto de chaves. As definições das diversas constantes de acessibilidade do conjunto de chaves são as seguintes:kSecAttrAccessibleAfterFirstUnlock
:kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
:kSecAttrAccessibleAlways
:kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
:kSecAttrAccessibleAlwaysThisDeviceOnly
:kSecAttrAccessibleWhenUnlocked
:kSecAttrAccessibleWhenUnlockedThisDeviceOnly
:kSecAttrAccessibleAlways
resulta no uso de uma chave derivada unicamente baseada no UID do dispositivo pela criptografia. Isso faz com que esses arquivos sejam acessíveis a qualquer momento em que o dispositivo estiver ligado, mesmo quando está iniciando ou bloqueado com uma senha. Como tal, os usos de kSecAttrAccessibleAlways
deverão ser estudados cautelosamente para determinar se uma proteção aprofundada com um nível de acessibilidade de conjunto de chaves mais rigoroso é garantida.
...
// Configure KeyChain Item
let token = "secret"
var query = [String : AnyObject]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecValueData as String] = token as AnyObject?
...
query[kSecAttrAccessible as String] = kSecAttrAccessibleAlways
SecItemAdd(query as CFDictionary, nil)
...
Realm
não criptografado:
Realm realm = Realm.getDefaultInstance();
Realm
não criptografado:
RLMRealmConfiguration *config = [RLMRealmConfiguration defaultConfiguration];
RLMRealm *realm = [RLMRealm realmWithConfiguration:config error:nil];
Realm
não criptografado:
let realm = try! Realm()
UIImageWriteToSavedPhotosAlbum
para salvar imagens no álbum de fotos:
- (void) imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary *)info
{
// Access the uncropped image from info dictionary
UIImage *image = [info objectForKey:UIImagePickerControllerOriginalImage];
// Save image
UIImageWriteToSavedPhotosAlbum(image, self, @selector(image:didFinishSavingWithError:contextInfo:), nil);
...
}
UIImageWriteToSavedPhotosAlbum
para salvar imagens no álbum de fotos:
func imagePickerController(picker: UIImagePickerController, didFinishPickingMediaWithInfo info: [NSObject : AnyObject]) {
if let pickedImage = info[UIImagePickerControllerOriginalImage] as? UIImage {
imageView.contentMode = .ScaleAspectFit
imageView.image = pickedImage
}
// Save image
UIImageWriteToSavedPhotosAlbum(pickedImage!, self, nil, nil)
dismissViewControllerAnimated(true, completion: nil)
}
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
:kSecAttrAccessibleAlways
:kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
:kSecAttrAccessibleAlwaysThisDeviceOnly
:kSecAttrAccessibleWhenUnlocked
:kSecAttrAccessibleWhenUnlockedThisDeviceOnly
:kSecAttrAccessibleWhenUnlocked
, se o dispositivo for roubado e uma senha for definida, o roubo precisará desbloquear o dispositivo para que os itens de conjunto de chaves sejam descriptografados. A falha ao digitar a senha correta bloqueará a descriptografia dos itens de conjunto de chaves do roubo. No entanto, se a senha não estiver definida, o invasor só precisará deslizar o dedo para desbloquear o dispositivo e obter o conjunto de chaves para descriptografar os itens. Portanto, a falha ao aplicar uma senha no dispositivo pode enfraquecer o mecanismo de criptografia do conjunto de chaves.
...
NSMutableDictionary *dict = [NSMutableDictionary dictionary];
NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];
// Configure KeyChain Item
[dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
[dict setObject:token forKey:(__bridge id)kSecValueData];
...
[dict setObject:(__bridge id)kSecAttrAccessibleWhenUnlockedThisDeviceOnly forKey:(__bridge id) kSecAttrAccessible];
OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
:kSecAttrAccessibleAlways
:kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly
:kSecAttrAccessibleAlwaysThisDeviceOnly
:kSecAttrAccessibleWhenUnlocked
:kSecAttrAccessibleWhenUnlockedThisDeviceOnly
:kSecAttrAccessibleWhenUnlocked
, se o dispositivo for roubado e uma senha for definida, o roubo precisará desbloquear o dispositivo para que os itens de conjunto de chaves sejam descriptografados. A falha ao digitar a senha correta bloqueará a descriptografia dos itens de conjunto de chaves do roubo. No entanto, se a senha não estiver definida, o invasor só precisará deslizar o dedo para desbloquear o dispositivo e obter o conjunto de chaves para descriptografar os itens. Portanto, a falha ao aplicar uma senha no dispositivo pode enfraquecer o mecanismo de criptografia do conjunto de chaves.
...
// Configure KeyChain Item
let token = "secret"
var query = [String : AnyObject]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecValueData as String] = token as AnyObject?
...
query[kSecAttrAccessible as String] = kSecAttrAccessibleWhenUnlockedThisDeviceOnly
SecItemAdd(query as CFDictionary, nil)
...