---

---

Entenent els Riscos i les Vulnerabilitats

En el món de les aplicacions web, és habitual transmetre dades al client amb l’expectativa que siguin enviades de tornada al servidor en sol·licituds posteriors. Aquesta transferència de dades sovint es facilita mitjançant mecanismes que oculten les dades de la visibilitat o la modificació directa per part de l’usuari. No obstant això, confiar únicament en la suposició que les dades transmeses a través del client romandran inalterades és una greu negligència que pot deixar les aplicacions vulnerables a diversos tipus d’atacs.

Per què Transmetre Dades a través del Client?

A primera vista, la necessitat de transmetre dades al client i després tornar-les a enviar al servidor pot semblar contraintuïtiva. Després de tot, si el servidor ja posseeix i especifica certes dades, per què involucrar el client en el procés de transmissió?

En realitat, hi ha diverses raons per les quals els desenvolupadors trien aquest enfocament:

• Gestió de Dades de Sessió: La transmissió de dades a través del client pot alleujar la càrrega de gestionar dades específiques de la sessió al servidor. Aquesta reducció en l’emmagatzematge de dades al costat del servidor pot millorar el rendiment de l’aplicació.
• Implementacions en Múltiples Servidors: En escenaris on una aplicació s’implementa en diversos servidors, compartir dades al costat del servidor entre amfitrions pot ser complicat. Utilitzar el client com a intermediari per a la transmissió de dades pot simplificar aquest procés.
• Integració amb Components de Tercers: Incorporar components de tercers, com carros de la compra, en una aplicació pot presentar dificultats en termes de modificació. La transmissió de dades a través del client ofereix una solució per a una integració perfecta.
• Desenvolupament àgil: Actualitzar APIs principals al costat del servidor per a acomodar noves dades pot ser laboriós i consumir temps. Implementar la transmissió de dades al costat del client proporciona una solució més àgil, permetent als desenvolupadors complir terminis ajustats sense modificacions extenses al backend.

Tot i que aquests motius poden simplificar els processos de desenvolupament, també introdueixen riscos significatius de seguretat.

Riscos de Transmetre Dades a través del Client

Un dels principals riscos associats amb la transmissió de dades a través del client és el potencial de modificació o manipulació no autoritzada. Ja que totes les dades enviades des del client al servidor es troben sota el control de l’usuari, qualsevol suposició que no seran modificades al llarg del camí és inherentment errònia. Aquesta vulnerabilitat pot ser explotada de diverses maneres, incloent:

Camps de Formularis Ocults

Els camps de formularis HTML ocults són un mecanisme comú per a la transmissió de dades a través del client d’una manera aparentment inalterable. Aquests camps no es mostren a l’usuari a la pantalla, però els seus noms i valors encara s’inclouen en els enviaments de formularis que es retornen al servidor.

Per exemple, considerem una aplicació de venda al detall que emmagatzema els preus dels productes dins de camps de formularis ocults. Malgrat no ser visibles per a l’usuari, aquests camps són vulnerables a la manipulació. Mitjançant l’intercepció i la modificació dels enviaments de formularis, els atacants poden alterar els preus i potencialment explotar la lògica transaccional de l’aplicació.

Explotant Camps de Formularis Ocults

La vulnerabilitat dels camps de formularis ocults es pot demostrar amb un exemple senzill. En un formulari HTML típic, un camp ocult anomenat «preu» podria emmagatzemar el cost d’un producte. Tot i que aquest camp no és visible per a l’usuari, el seu valor es transmet al servidor quan es presenta el formulari.

<form method="post" action="Shop.aspx?prod=1">
  Producte: iPhone 5 <br/>
  Preu: 449 <br/>
  Quantitat: <input type="text" name="quantitat"> (Quantitat màxima és 50)
  <br/>
  <input type="hidden" name="preu" value="449">
  <input type="submit" value="Comprar">
</form>

Tot i que el camp no és visible, el seu valor es pot modificar ja sigui editant el codi font HTML o utilitzant proxies d’interceptació com Burp Suite. Amb accés al proxy d’interceptació, els atacants poden manipular els valors dels camps de formularis ocults en trànsit, potencialment alterant els resultats de les transaccions a favor seu.

Cookies HTTP

Un altre mecanisme comú per a la transmissió de dades a través del client són les cookies HTTP. Al igual que amb els camps de formulari ocults, normalment no es mostren a la pantalla i l’usuari no pot modificar-los directament. No obstant això, poden ser modificats utilitzant un proxy d’intercepció, canviant ja sigui la resposta del servidor que els estableix o les sol·licituds del client posteriors que els emeten.

Considera la següent variació de l’exemple anterior. Després que el client hagi iniciat sessió a l’aplicació, rep la següent resposta:

HTTP/1.1 200 OK
Set-Cookie: DescompteAcordat=25
Content-Length: 1530
...

Aquesta cookie de DescompteAcordat apunta a un cas clàssic de confiar en controls del costat del client (el fet que les cookies normalment no es poden modificar) per protegir dades transmeses a través del client. Si l’aplicació confia en el valor de la cookie DescompteAcordat quan és enviada de tornada al servidor, els clients poden obtenir descomptes arbitraris modificant-ne el valor.

Per exemple:

POST /botiga/92/Comprar.aspx?prod=3 HTTP/1.1
Host: mdsec.net
Cookie: DescompteAcordat=25
Content-Length: 10
quantitat=1

Paràmetres d’URL

Les aplicacions transmeten freqüentment dades a través del client utilitzant paràmetres d’URL preestablerts.

 xxxx/botiga/?prod=3&codidepreu=32

Quan una URL que conté paràmetres es mostra a la barra d’ubicació del navegador, qualsevol usuari pot modificar fàcilment els paràmetres sense l’ús d’eines. No obstant això, en molts casos, una aplicació pot esperar que els usuaris ordinaris no puguin veure ni modificar els paràmetres d’URL.

Per descomptat, en qualsevol cas així, els valors de qualsevol paràmetre d’URL es poden modificar com es va discutir anteriorment utilitzant un proxy d’intercepció.

Capçalera Referer

Els navegadors inclouen la capçalera Referer en la majoria de les sol·licituds HTTP. S’utilitza per indicar la URL de la pàgina des de la qual va originar-se la sol·licitud actual, ja sigui perquè l’usuari va fer clic en un hipervincle o va enviar un formulari, o perquè la pàgina feia referència a altres recursos com ara imatges. Per tant, es pot aprofitar com a mecanisme per a la transmissió de dades a través del client.

Per exemple, considera un mecanisme que permet als usuaris restablir la seva contrasenya si l’han oblidat. L’aplicació requereix que els usuaris passin per diversos passos en una seqüència definida abans que realment restableixin el valor de la seva contrasenya amb la següent sol·licitud:

GET /autenticacio/472/CreaUsuari.ashx HTTP/1.1
Host: mdsec.net
Referer: https://xxxxx.net/autenticacio/xxx/Admin.ashx

L’aplicació pot utilitzar la capçalera Referer per verificar que aquesta sol·licitud es va originar a l’etapa correcta (Admin.ashx). Si ho va fer, l’usuari pot accedir a la funcionalitat sol·licitada.

No obstant això, ja que l’usuari controla tots els aspectes de cada sol·licitud, incloses les capçaleres HTTP, aquest control pot ser fàcilment eludit procedint directament a CreaUsuari.ashx i utilitzant un proxy d’intercepció per canviar el valor de la capçalera Referer al valor que l’aplicació requereix.

La capçalera Referer és estrictament opcional segons els estàndards de w3.org. Per tant, tot i que la majoria dels navegadors la implementen, utilitzar-la per controlar la funcionalitat de l’aplicació s’ha de considerar com a un hack.

MITE COMÚ

Sovint s’assumeix que les capçaleres HTTP són d’alguna manera més «a prova de manipulacions» que altres parts de la sol·licitud, com ara la URL. Això pot portar els desenvolupadors a implementar funcionalitats que confien en els valors enviats en capçaleres com Cookie i Referer mentre realitzen una validació adequada d’

altres dades com ara els paràmetres d’URL. No obstant això, aquesta percepció és falsa. Donada la multitud de eines de proxy d’intercepció que estan disponibles gratuïtament, qualsevol hacker aficionat que ataqués una aplicació pot canviar totes les dades de la sol·licitud amb facilitat. És una mica com suposar que quan el mestre ve a buscar al teu escriptori, és més segur amagar la teva pistola d’aigua al calaix de sota, perquè haurà de doblegar-se més per descobrir-la.

PASSOS PER PIRATEJAR

1. Localitza totes les instàncies dins de l’aplicació on aparentment s’estan utilitzant camps de formulari ocults, cookies i paràmetres d’URL per a la transmissió de dades a través del client.
2. Intenta determinar o endevinar el paper que juga l’element en la lògica de l’aplicació, basant-te en el context en què apareix i en pistes com ara el nom del paràmetre.
3. Modifica el valor de l’element de formes que siguin rellevants per al seu propòsit en l’aplicació. Assegura’t si l’aplicació processa valors arbitraris enviats en el paràmetre, i si això exposa l’aplicació a alguna vulnerabilitat.

Dades Opaces

A vegades, les dades transmeses a través del client no són transparentment intel·ligibles perquè han estat encriptades o oscuregudes d’alguna manera. Per exemple, en lloc de veure el preu d’un producte emmagatzemat en un camp ocult, pots veure un valor críptic que es transmet:

<form method=”post” action=”Botiga.aspx?prod=4”>
  Producte: Nokia Infinity <br/>
  Preu: 699 <br/>
  Quantitat: <input type=”text” name=”quantitat”> (Quantitat màxima és 50)
  <br/>
  <input type=”hidden” name=”preu” value=”699”>
  <input type=”hidden” name=”token_de_preu” value=”E76D213D291B8F216D694A34383150265C989229”>
  <input type=”submit” value=”Comprar”>
</form>

Quan això es observa, pots inferir raonablement que quan s’envia el formulari, l’aplicació del costat del servidor verifica la integritat de la cadena opaca, o fins i tot la desxifra o oscureix per realitzar algun processament en el seu valor en text pla. Aquest processament addicional pot ser vulnerable a qualsevol tipus d’error. No obstant això, per sondejar i explotar això, primer necessites embolicar la teva càrrega útil adequadament.

NOTA

Els elements de dades opaques transmesos a través del client sovint formen part del mecanisme de gestió de sessions de l’aplicació. Tokens de sessió enviats en cookies HTTP, tokens anti-CSRF transmesos en camps ocults i tokens d’URL d’un sol ús per accedir a recursos de l’aplicació, són tots objectius potencials per a la manipulació del costat del client. Nombroses consideracions són específiques per a aquests tipus de tokens .

PASSOS PER PIRATEJAR

Davant la presència de dades opaques transmeses a través del client, són possibles diverses vies d’atac:

1. Si coneixes el valor del text pla darrere de la cadena opaca, pots intentar desxifrar l’algoritme d’oscureixement que s’està utilitzant.
2. L’aplicació pot contenir funcions en altres llocs que pots aprofitar per retornar la cadena opaca resultant d’un fragment de text pla que controles. En aquesta situació, és possible que puguis obtenir directament la cadena requerida per enviar una càrrega útil arbitrària a la funció que estàs apuntant.
3. Incluso si la cadena opaca és impenetrable, pot ser possible reproduir el seu valor en altres contextos per assolir un efecte maliciós. Per exemple, el paràmetre token_de_preu en el formulari mostrat anteriorment pot contenir una versió xifrada del preu del producte. Tot i que no és possible produir l’equivalent xifrat per a un preu arbitrari de la teva elecció, és possible que puguis copiar el preu xifrat d’un producte diferent, més econòmic, i enviar-lo en el seu lloc.
4. Si tot falla, pots intentar atacar la lògica del costat del servidor que desxifrarà o oscureixarà la cadena opaca enviant variacions malformades de la mateixa, per exemple, contenen valors massa llargs, diferents conjunts de caràcters, i similars.

Captura de Dades de l’Usuari: Formularis HTML

L’altra manera principal en què les aplicacions utilitzen controls del costat del client per restringir les dades enviades pels clients es produeix amb les dades que no van ser especificades originalment pel servidor, sinó que es van recollir al propi ordinador del client.

Els formularis HTML són la manera més senzilla i comuna de capturar l’entrada de l’usuari i enviar-la al servidor. Amb els usos més bàsics d’aquest mètode, els usuaris escriuen dades en camps de text amb noms, que s’envien al servidor com parells de nom/valor. No obstant això, els formularis es poden utilitzar de d’altres maneres; poden imposar restriccions o realitzar comprovacions de validació sobre les dades subministrades per l’usuari. Quan una aplicació empra aquests controls del costat del client com a mecanisme de seguretat per defensar-se contra entrades malintencionades, els controls solen poder ser fàcilment eludits, deixant l’aplicació potencialment vulnerable a atacs.

Límits de Longitud

Considera la següent variació de l’original formulari HTML, que imposa una longitud màxima de 1 al camp quantitat:

<form method=”post” action=”Botiga.aspx?prod=1”>
  Producte: iPhone 5 <br/>
  Preu: 449 <br/>
  Quantitat: <input type=”text” name=”quantitat” maxlength=”1”> <br/>
  <input type=”hidden” name=”preu” value=”449”>
  <input type=”submit” value=”Comprar”>
</form>

Aquí, el navegador impedeix a l’usuari introduir més d’un caràcter al camp d’entrada, de manera que l’aplicació del costat del servidor pot assumir que el paràmetre de quantitat que rep serà menor que 10. No obstant això, aquesta restricció es pot eludir fàcilment bé interceptant la sol·licitud que conté l’enviament del formulari per introduir un valor arbitrari, o bé interceptant la resposta que conté el formulari per eliminar l’atribut maxlength.

INTERCEPCIÓ DE RESPOSTES

Quan intentis interceptar i modificar les respostes del servidor, pots trobar que el missatge rellevant mostrat al teu proxy és així:

HTTP/1.1 304 Not Modified
Date: Wed, 6 Jul 2011 22:40:20 GMT
Etag: “6c7-5fcc0900”
Expires: Thu, 7 Jul 2011 00:40:20 GMT
Cache-Control: max-age=7200

Aquesta resposta es produeix perquè el navegador ja té una còpia en memòria cau del recurs que ha sol·licitat. Quan el navegador sol·licita un recurs emmagatzemat en memòria cau, normalment afegeix dues capçaleres a la sol·licitud: If-Modified-Since i If-None-Match:

GET /scripts/validate.js HTTP/1.1
Host: wahh-app.com
If-Modified-Since: Sat, 7 Jul 2011 19:48:20 GMT
If-None-Match: “6c7-5fcc0900”

Aquestes capçaleres indiquen al servidor quan el navegador va actualitzar per última vegada la seva còpia emmagatzemada en memòria cau. La cadena Etag, que el servidor va proporcionar amb aquella còpia del recurs, és una mena de número de sèrie que el servidor assigna a cada recurs que es pot emmagatzemar en memòria cau. Es actualitza cada vegada que el recurs es modifica. Si el servidor té una versió més nova del recurs que la data especificada a la capçalera If-Modified-Since, o si l’Etag de la versió actual coincideix amb el que es va especificar a la capçalera If-None-Match, el servidor respon amb l’última versió del recurs. En cas contrari, retorna una resposta 304, com es mostra aquí, informant al navegador que el recurs no ha estat modificat i que el navegador hauria de fer servir la seva còpia en memòria cau.

Quan això ocorre, i necessites interceptar i modificar el recurs que el navegador ha emmagatzemat en memòria cau, pots interceptar la sol·licitud rellevant i eliminar les capçaleres If-Modified-Since i If-None-Match. Això fa que el servidor respongui amb la versió completa del recurs sol·licitat. Burp Proxy conté una opció per eliminar aquestes capçaleres de totes les sol·licituds, substituint així tota la informació de la memòria cau enviada pel navegador.

PASSOS PER PIRATEJAR

1. Busca elements de formulari que continguin un atribut maxlength. Envia dades que siguin més llargues que aquesta longitud però que estiguin correctament formatades en altres aspectes (per exemple, siguin numèriques si l’aplicació espera un número).
2. Si l’aplicació accepta les dades excessives en longitud, pots deduir que la validació del costat del client no es replica al servidor.
3. Depenent del processament posterior que realitzi l’aplicació en el paràmetre, pots aprofitar els defectes de validació per explotar altres vulnerabilitats, com ara la injecció SQL, l’scripting entre llocs o les desbordaments de buffer.

Conclusió

La transmissió de dades a través del client ofereix comoditat en el desenvolupament d’aplicacions, però comporta significatives implicacions de seguretat. Els camps de formularis ocults, tot i semblar segurs, són vulnerables a la manipulació, exposant les aplicacions a l’explotació. Per mitigar aquests riscos, els desenvolupadors han de prioritzar una validació robusta al costat del servidor i adoptar pràctiques segures de transmissió de dades, garantint la integritat i la confidencialitat de les dades de l’usuari. Només a través d’una atenció diligent a la seguretat, les aplicacions poden resistir les nombroses amenaces derivades de les vulnerabilitats de transmissió de dades al costat del client.