Detectarea Atacurilor Asupra Aplicațiilor Web Din Fișierele Jurnal

13.10.
2021, 21:55 WHITE PAPER Detectarea atacurilor asupra aplicațiilor web din fișierele jurnal
Pagina 1
HARTIE ALBA
Detectarea atacurilor
pe aplicații Web
din Fișiere jurnal
Roger Meyer
Copyright SANS Institute 2021. Autorul își păstrează drepturile depline.

Această lucrare a fost publicată de Institutul SANS. Repostarea nu este permisă fără permisiunea scrisă expresă.
Pagina 2
https://translate.googleusercontent.com/translate_f 1/39
13.10.2021, 21:55 WHITE PAPER Detectarea atacurilor asupra aplicațiilor web din fișierele jurnal
Detectarea atacurilor pe aplicații web

din Fișiere jurnal
8, Autorul își păstrează drepturile

Amprentă cheie = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
Certificare GCIA Gold
Autor: Roger Meyer
Consilier: Carlos Cid
Acceptat: 26 ianuarie 2008
© SANS Institute 200
© Institutul SANS 2008, Ca parte a sălii de lectură privind securitatea informațiilor Autorul își păstrează drepturile depline.
@ 2021 Institutul SANS Autorul își păstrează drepturile depline
Pagina 3
Detectarea atacurilor pe aplicații web
Contur
1 Rezumat ................................................ ...... 3

2 Introducere ................................................ ..4
3 Atacuri pe aplicații web ................................... 5
3.1 Fișiere jurnal server web ...................................... 6
3.2 Primer pe HTTP ............................................... 8
3.2.1 Tehnici de evaziune HTTP .............................. 12
3.3 Expresii regulate (Regex) .............................. 14
4 Detectarea atacurilor ............................................... 15
4.1 Detecție bazată pe reguli (reguli statice) ...................... 20
4.1.1 Model de securitate negativ .............................. 20
4.1.2 Model de securitate pozitivă .............................. 21
4.2 Detecție bazată pe anomalii (reguli dinamice) .................. 21
4.3 Detectarea Top Ten OWASP 2007 ......................... 22
4.3.1 A1 Cross Site Scripting (XSS) ...................... 22
4.3.2 Defecțiuni la injecție A2 ................................. 26
4.3.3 Executarea fișierelor rău intenționate A3 ....................... 32
4.3.4 Referință directă a obiectului A4 nesigur ................ 33
4.3.5 A5 Falsificare de cereri de site-uri încrucișate (CSRF) ............... 35
4.3.6 Scurgerea informațiilor A6 și gestionarea necorespunzătoare a erorilor. 37
4.3.7 A7 Autentificare defectă și gestionarea sesiunii. . . .38
4.3.8 A8 Stocare criptografică nesigură .................. 39

Amprentă cheie = 4.3.9
AF19 A9 Comunicări
FA27 2F94 998D FDB5 nesigure
DE3D.......................
F8B5 06E4 A16940 4E46
4.3.10 A10 Eșecul restricționării accesului URL ................ 41
5. Concluzie................................................ ... 42
6 Referințe ................................................ ... 42

Roger Meyer 2
Pagina 4
Abstract Detectarea atacurilor pe aplicații web
1 Rezumat
Traficul web (Hypertext Transfer Protocol, HTTP) a depășit

Traficul P2P și continuă să crească. [Ellacoya, 2007] Hacks site-uri web
sunt în creștere și reprezintă o amenințare mai mare decât cea largă
atacuri de rețea, deoarece amenință să fure clienți critici,

informații despre angajați și parteneri de afaceri stocate în aplicații
și baze de date legate de web. [Greenemeier, 2006]
Trecerea tot mai mare către aplicațiile web se deschide nouă

vectori de atac. Mecanisme tradiționale de protecție precum firewall-urile
nu au fost concepute pentru a proteja aplicațiile web și astfel nu
asigură o apărare adecvată. Atacurile actuale nu pot fi contracarate de
doar blocarea porturilor 80 (HTTP) și 443 (HTTPS).
Măsurile preventive (cum ar fi regulile Firewall pentru aplicații web) sunt

nu întotdeauna posibil. Metode reactive - pentru a detecta ce s-a întâmplat
anterior - sunt de obicei mai ușoare, dar au dezavantajul de
fiind întotdeauna în spatele evenimentului propriu-zis.
Această lucrare explică modul de detectare a celui mai critic web

defecte de securitate ale aplicației. Fișierele jurnal ale aplicațiilor web permit o
analiza detaliată a acțiunilor unui utilizator. Fișierele jurnal au limitele sale,
deşi. Fișierele jurnal ale serverului web conțin doar o fracțiune din total
Solicitare și răspuns HTTP. Cunoscând aceste limite, majoritatea
atacurile pot fi recunoscute și acționate pentru a preveni în continuare
exploatare.

Roger Meyer 3
Pagina 5
Introducere Detectarea atacurilor pe aplicații web
2 Introducere
Utilizarea internetului și aplicațiile online se confruntă

creștere spectaculoasă. La nivel mondial, există peste un miliard de Internet
utilizatori în prezent. Un motiv important pentru succesul internetului este
simplitatea și din care puteți accesa aplicațiile
oriunde. Această creștere a popularității nu a trecut neobservată de
element criminal - simplitatea protocolului HTTP îl face
ușor de furat și falsifică identitatea. Răspunderea în afaceri
asociată cu protejarea informațiilor online a crescut

în mod semnificativ și aceasta este o problemă care trebuie abordată.
SANS Top20 Internet Security Attack Targets (Anual 2007

Actualizare) [SANS Top20, 2007] este o listă consensuală a vulnerabilităților
care necesită remedierea imediată. Conform acestei liste
vulnerabilitatea numărul unu vizată de server este Web
Aplicații. Câteva exemple de aplicații web sunt Conținut

Sisteme de management (CMS), Wikis, portaluri, panouri, magazine,

Sisteme bancare și forumuri de discuții. Există o mulțime de online
resursele care afirmă că aplicațiile web sunt printre cele mai multe
ținte atacate ([SC Magazine, 2007] și [IT Week, 2006]).
Acest lucru a făcut din detectarea și prevenirea acestor activități un top

prioritate pentru fiecare companie importantă. Acest referat abordează
detectarea atacurilor asupra aplicațiilor web prin analiza fișierelor jurnal
de pe servere web (cum ar fi Apache și IIS). De ce ar trebui să te deranjezi
analizând fișierele jurnal în loc să utilizeze o detectare a intruziunilor în rețea
sistem? Ar putea exista mai multe motive pentru aceasta:

● Traficul HTTP poate fi criptat SSL (HTTPS);
● Este posibil să nu existe NIDS (greu de implementat; o altă zonă de

atac);
Roger Meyer 4
Pagina 6
Introducere Detectarea atacurilor pe aplicații web
● Încărcarea mare de trafic face dificilă analiza rețelei

trafic (în timp real);
● NIDS sunt concepute pentru a funcționa la nivelul TCP / IP, și astfel

este posibil să nu fie la fel de eficiente în stratul HTTP;
● tehnici de evaziune IDS (HTTP, codificare,

fragmentare, ...).
Analiza traficului web din fișierele jurnal are unele avantaje

și dezavantaje față de analiza traficului din rețea. Acestea
diferențele vor fi explorate în capitolul ' 4 . Detectare

Atacuri '.
3 Atacuri pe aplicații web
Atacurile asupra aplicațiilor web sunt în continuă schimbare. A

raportul de la Fortify Software Inc. [Fortify, 2006] prezintă patru
tendinte:
● Roboții sunt folosiți în mai mult de jumătate din atacurile împotriva

aplicații web;
● Atacatorii găsesc aplicații web defecte folosind

Google și alte instrumente de căutare;
● Atacurile direcționate sunt din ce în ce mai sofisticate; și
● Atacatorii care operează din baze din întreaga lume sunt
devenind mai bine la acoperirea urmelor lor.
Tendințe similare au fost găsite de [KYE: Web Application

Amenințări, 2007]. În timp ce majoritatea atacurilor automatizate au fost bine cunoscute
aplicații precum PHPBB, Mambo, AWStats etc., aplicație web
defectele de securitate pot fi clasificate și evaluate. Top Zece OWASP
Roger Meyer 5
Pagina 7
Atacuri pe aplicații web Detectarea atacurilor pe aplicații web
Proiectul [OWASP Top Ten Project, 2007] enumeră cele mai importante 10
defecte de securitate a aplicațiilor web. Fundația OWASP este o notfor
organizație de profit care oferă informații despre cerere
Securitate. Scopul principal al Top 10 al OWASP este de a educa
dezvoltatori, designeri, arhitecți și organizații despre

consecințele celei mai comune securități a aplicațiilor web
vulnerabilități. În capitolul „ 4.3 Detectarea primelor zece OWASP”
vom intra în detalii despre cum să detectăm aceste atacuri.
Actualizarea din 2007 a adus câteva vulnerabilități noi, cum ar fi

Executarea fișierelor rău intenționate și falsificarea cererilor pe site-uri încrucișate (CSRF).
Cel mai mare salt înainte a fost făcut de Cross Site Scripting (XSS)
deşi. Astăzi, în general, se crede că XSS este unul dintre cele mai multe
tehnici obișnuite de hacking în straturi de aplicație.
Atacatorii vizează aplicații web cu diferite

scopuri. Fiecare defect are propria sa consecință. Atacuri precum XSS (A1)

și CSRF (A5) vizează utilizatorii aplicațiilor, în timp ce toți ceilalți
(Top 10) atacurile vizează aplicația web în sine. Luând

avantajul vulnerabilităților XSS permite atacatorului să introducă
codul activ în browserul unui utilizator și executarea acestuia în context
a aplicației curente. Exploatarea defectelor de injecție, de exemplu
vizează de obicei direct aplicația prin inserarea de programe rău intenționate
cod în backend sau citind date neautorizate din
Bază de date.
3.1 Fișiere jurnal server web
Serverele web standard precum Apache și IIS generează jurnalizare

mesaje implicite în specificația Common Log Format (CLF).

Fișierul jurnal CLF conține o linie separată pentru fiecare solicitare HTTP. A
linia este compusă din mai multe jetoane separate prin spații:
Roger Meyer 6
Pagina 8
gazdă identitate identificator date cerere stare octeți
Dacă un simbol nu are o valoare, atunci acesta este reprezentat de un

cratimă (). Jetoanele au aceste semnificații:
● gazdă: numele de domeniu complet calificat al clientului sau

adresa IP a acestuia.
● ident: Dacă directiva IdentityCheck este activată și

computerul rulează identd, atunci aceasta este identitatea
informații raportate de client.
● autentificator: dacă adresa URL solicitată a necesitat un succes

Autentificare HTTP de bază, atunci numele de utilizator este valoarea
a acestui semn.
● data: data și ora solicitării.
● cerere:
Linia de cerere de la client, inclusă în
ghilimele duble (").
● status: Codul de stare HTTP cu trei cifre returnat la

client.
● octeți: numărul de octeți din obiectul returnat la

client, excluzând toate anteturile HTTP.
O cerere poate conține date suplimentare, cum ar fi rezultatul și

șirul agentului utilizator. Să luăm în considerare un exemplu de intrare jurnal (în
formatul jurnalului combinat [Apache Combined Log Format, 2007]):
127.0.0.1 franc [10 / Oct / 2007: 13: 55: 36 0700]

„GET /index.html HTTP / 1.0” 200 2326
„http://www.example.com/links.html” „Mozilla / 4.0 (compatibil; MSIE
7,0; Windows NT 5.1; .NET CLR 1.1.4322) "
Roger Meyer 7
Pagina 9
127.0.0.1: adresa IP a clientului
: „Cratima” din ieșire indică faptul că solicitarea

informația nu este disponibilă. În acest caz,
informațiile care nu sunt disponibile sunt identitatea RFC 1413 a
client determinat de identd pe computerul clientului.
franc: Acesta este user-ul persoanei care solicită

document determinat de autentificarea HTTP.
[10 / Oct / 2007: 13: 55: 36 0700]: Ora în care serverul
a finalizat procesarea cererii.
„GET /index.html HTTP / 1.0”: linia de solicitare de la client

este dat în ghilimele duble.
200: Acesta este codul de stare la care serverul trimite înapoi

clientul.

2326: Această intrare indică dimensiunea obiectului returnat

către client, fără a include antetele de răspuns.
„http://www.example.com/links.html”: „Referer” (sic)

Antetul cererii HTTP.
"Mozilla / 4.0 (compatibil; MSIE 7.0; Windows NT 5.1; .NET CLR

1.1.4322) ": antetul cererii HTTP UserAgent.
3.2 Primer pe HTTP
HTTP (prescurtarea pentru Hyper Text Transfer Protocol) este limba

că vorbesc serverele web și browserele. Standardele de internet sunt

propus, discutat și, în cele din urmă, specificat în documente cunoscute
ca RFC (Cerere de comentarii) și HTTP nu face excepție:
ultima încarnare, Rev. 1.1, este descrisă în RFC 2616 [Fielding
Roger Meyer 8
Pagina 10
și colab., 1999].
HTTP este un sistem de solicitare / răspuns. Numai clientul este permis

pentru a face cereri. Solicită serverului web să livreze un anumit
pagină. Dacă fișierul nu poate fi localizat, se trimite un răspuns la eroare
in schimb. O astfel de locație pe un server web este descrisă cu
Localizatori universali de resurse sau adrese URL:
sistem: //gazdă [:port] / cale / către / rez [? interogare]
ource
Protocol FQDN al Opțional Locația Opțional

identificator, gazdă: de ex numarul portului the context
de exemplu, http, www.exemplu. din resursă, ca informație
https, ftp com serviciu: de ex cunoscut de
80 Server
Într-o cerere HTTP, clientul contactează serverul prin intermediul
rețea și trimite o solicitare formatată corespunzător care descrie ce
resursa pe care o dorește. Acesta este ambalat în bucăți numite cerere

antetul și corpul cererii. Serverul analizează cererea, dacă
posibil o realizează și reacționează returnând dacă
operațiunea a avut succes, orice metainformație cu privire la

datele despre rezultate (dacă există) și conținutul care a fost recuperat ca rezultat
a tranzacției. Acesta este formatat și ambalat în bucăți cunoscute
ca stare a serverului, anteturile de răspuns și corpul de răspuns.
Să aruncăm o privire la ceea ce clientul și serverul de fapt

spune-i unul altuia. Cea mai de bază cerere este un GET tipic

tranzacție, în care un browser web solicită trimiterea unei pagini HTML.
Roger Meyer 9
Pagina 11
Clientul
GET /index.html HTTP / 1.1 Tipul cererii (GET), calea,
protocol și versiune.
Gazdă: www.example.com Gazda pentru care este adresată această solicitare.
UserAgent: Mozilla / 5.0 (X11; U; Identificatorul clientului.

Linux i686; enUS; rv: 1.8.1.8)
Gecko / 20071004 Iceweasel / 2.0.0.8
(Debian2.0.0.81)
Accept: Tipuri de date și codificare
text / xml, application / xml, applica clientul poate gestiona (tipuri MIME).
tion / xhtml
+ xml, text / html; q = 0,9, text / simplu;

Amprentăqcheie
= 0,8, imagine
= AF19 FA27/2F94
png,998D
* / *;FDB5
q = DE3D
0,5 F8B5 06E4 A169 4E46
AcceptLanguage: enus, en; q = 0,5
AcceptEncoding: gzip, deflate
AcceptCharset:
ISO88591, utf8; q = 0,7, *; q = 0,7
KeepAlive: 300 Păstrați conexiunea deschisă pentru

cereri suplimentare.
Conexiune: keepalive Nu închideți conexiunea.

Roger Meyer 10
Pagina 12
Server-ul
HTTP / 1.x 200 OK Starea rezultatului: numerică și

Descriere.
Data: vineri, 14 decembrie 2007 10:25:51 Timestamp-ul.

GMT
Server: Apache Identificatorul serverului
software.
ContentType: text / html; Informații formatate MIME pe

set de caractere = ISO88591 tipul (html) al rezultatului.
O linie goală separă

anteturi de răspuns din
corp de răspuns.

<! DOCTYPE HTML PUBLIC Acum documentul (HTML ca
"// W3C // DTD HTML 4.01 așteptat) este trimis.
Transitoriu // EN ">
...
Solicitarea GET îndeplinește nevoia de bază de a difuza un URL către un

client. Cererea POST, de exemplu, permite clientului să trimită
de date către server pentru procesare ulterioară și este fundamentul
pe care sunt construite formulare web completate. Toate aceste cereri,
totuși, urmați schema generală prezentată mai sus, dați sau luați un
câteva anteturi MIME.

Roger Meyer 11
Pagina 13
3.2.1 Tehnici de evaziune HTTP
Există diferite tipuri de evaziuni în diferite locuri ale

Protocol HTTP. Acestea pot apărea în porțiunea URI de solicitare a
Protocol HTTP, alte părți ale antetului HTTP, corpului HTTP etc.
Tipurile de evaziune pot fi evaziuni de decodare a protocolului, simple
tehnici de ofuscare sau evaziuni mai avansate, cum ar fi inserarea

caractere suplimentare pentru a înșela sistemul IDS. Evaziile sunt
deosebit de eficient împotriva adresei URL și a parametrilor URL. Noi
ne va pune accentul pe aceste două tipuri, deoarece ambele sunt vizibile
în fișierul jurnal al serverului web.
Primele evaziuni au fost la fel de simple ca adăugarea mai multor bare oblice
către directoare și alte atacuri de parcurgere a căilor. Următorul URI

au toate același sens:
/admin/index.html

//admin/index.html
/admin/./index.html
/admin/../admin/index.html
/admin/./../admin/index.html
Ar putea exista combinații infinite ale acestor evaziuni. The

Scopul acestor tehnici este de a eluda detectarea printr-un IDS, dar
rămâne în continuare executat de aplicația web. Iată câteva altele
metode de normalizare [WASC, 2006]:
1. Decodare URL (de ex.% XX)
2. Terminarea șirului de octet nul
3. Căi de autoreferențiere (adică utilizarea /./ și codificate

echivalente)
4. Referințe de cale înapoi (adică utilizarea /../ și codificate
Roger Meyer 12
Pagina 14
echivalente)
5. Carcasă mixtă
6. Utilizarea excesivă a spațiului alb
7. Eliminarea comentariilor (de exemplu, convertiți DELETE / ** / FROM în DELETE

DIN)
8. Conversia caracterelor de tip backslash (acceptate de Windows)

în caractere oblice înainte.
9. Conversia codificării Unicode IISspecifice (% uXXYY)
10. Decodarea entităților HTML (de exemplu, & # 99 ;, & quot ;, & # xAA;)
11. Caracterele evadate (de ex. \ T, \ 001, \ xAA, \ uAABB)
O tehnică de evaziune foarte populară este de a ofensa adresa URL și

parametrul său utilizând diferite scheme de codificare. Conform
[Roelker, 2003], există doar două standarde RFC pentru codificarea a
solicitați URI: codare hex și codificare Unicode UTF8. Ambele metode

sunt codificate folosind caracterul „%” pentru a scăpa de un octet codat.
Există alte scheme de codificare, dar toate acestea sunt specifice serverului
și care nu sunt compatibile cu RFC.
Codificare hexagonală
Codificarea hexagonală este cea mai simplă modalitate de codificare a unei adrese URL. Aceasta
constă în scăparea unei valori de octet hexazecimal pentru codificat
caracter cu un „%”. Pentru a codifica litera C, care are un ASCII
valoare hexazecimală de 0x43, codificarea ar arăta astfel:

●% 43 = „C”
Cum ar arăta o astfel de cerere într-un fișier jurnal? Să facem

Roger Meyer 13
Pagina 15
o altă solicitare (/index.html). Așa ar arăta:
● GET /index.html HTTP / 1.1
Acum codificăm URI-ul cu valori hexagonale:
● GET /% 69% 6E% 64% 65% 78% 2E% 68% 74% 6D% 6C HTTP / 1.1
Alte codificări sunt codificarea hexagonală cu procent dublu,

codare hexagonală dublă, prima codificare hexagonală și codul
a doua codificare hexagonală nibble. Acestea nu vor fi acceptate de toate site-urile web
server totuși.
Pentru alte variante de codificare cum ar fi codarea UTF8, vă rugăm să consultați
[Roelker, 2003] pentru o prezentare generală.
3.3 Expresii regulate (Regex)

Expresiile regulate permit o versiune puternică, flexibilă și
procesare eficientă a textului. Expresiile regulate vă permit, cu un
notația generală tipar aproape ca un mini limbaj de programare,
pentru a descrie și analiza textul. Acest puternic limbaj tipar și

tiparele în sine sunt numite expresii regulate.
Expresiile regulate sunt disponibile în multe tipuri de instrumente, dar

puterea lor este cel mai complet expusă atunci când este disponibilă ca parte a
limbaj de programare. Scopul unei expresii regulate este acela de a se potrivi
o anumită expresie într-o bucată de text.
Exemplu de expresie regulată:
/ (java)? script / i

Un model de expresie regulată este de obicei închis în interior
bare oblice ('/'). Această regex găsește toate aparițiile de „script” sau
Roger Meyer 14
Pagina 16
„javascript”. Modificatori, de obicei adăugați după linia de închidere,

permiteți setarea anumitor opțiuni, cum ar fi modelul cazensensibil
potrivire (modificatorul „i”).
Pentru mai multe informații despre expresiile regulate, consultați [Friedl,

1997].
4 Detectarea atacurilor
Aplicațiile web rulează pe OSI [OSI, 1994]

stratul 7 stratul de aplicare. Pentru a detecta atacuri împotriva web
aplicații, mecanismele de detectare trebuie să fie aplicații
conștientizează stratul și vezi traficul relevant.
Atacurile pot fi detectate în diferite zone și dispozitive din

infrastructura retelei. Fiecare loc are o vedere diferită asupra
trafic și are avantajele și dezavantajele sale. Acum mergem

pentru a explora fiecare dintre aceste locuri din rețea.

Ilustrația 1: Detectarea atacurilor într-o rețea
Roger Meyer 15
Pagina 17
Detectarea atacurilor Detectarea atacurilor pe aplicații web
Layer 3/4 Firewall
Un firewall tradițional (de stat și non-statial) funcționează

pe straturile OSI 3 (Network Layer) și 4 (Transport Layer). The
firewall-ul analizează traficul pe baza protocoalelor comune precum TCP,
UDP și ICMP și porturile sau tipurile / codurile corespunzătoare.
Firewall-urile pot detecta anomalii în protocoalele de care sunt conștiente
ca traficul IP fragmentat, dar în general nu sunt cele mai bune
loc pentru a detecta atacurile asupra stratului de aplicație. Jurnal firewall
fișierele nu conțin, de obicei, date de nivel de aplicație precum HTTP
date, doar informațiile de nivel 3 și 4, deci nu sunt foarte utile
în detectarea a ceea ce se întâmplă straturile superioare.
Firewall strat aplicație / firewall aplicație web (WAF)
Firewall-urile pentru aplicații web sunt proiectate să funcționeze pe OSI

stratul 7 (stratul de aplicare). Ei sunt pe deplin conștienți

protocoale de strat de aplicație precum HTTP (S) și SOAP și can
analizați aceste cereri în detaliu. Comparativ cu un strat 3/4
firewall, regulile pot fi definite pentru a permite / anula anumite HTTP
solicitări precum POST, PUSH, OPTIONS etc., stabilesc limite în fișier
dimensiunea transferului sau lungimea argumentului parametrului URL. Fișiere jurnal WAF
conține la fel de multe informații ca cele de pe un server web plus
deciziile de politică ale regulilor de filtrare (de exemplu, cererea HTTP blocată;
limita de dimensiune a transferului de fișiere atinsă etc.). Un WAF oferă o bogăție

de informații în scopuri de filtrare și detectare și este astfel un
un loc bun pentru detectarea atacurilor.
Server web
Serverul web este dispozitivul final al unei cereri HTTP. Standard

serverele web precum Apache și IIS se înregistrează în mod implicit în
Specificația Common Log Format (CLF). Vezi capitolul ' 3.1 Server web
fișiere jurnal 'pentru o descriere detaliată a formatului CLF.
Roger Meyer 16
Pagina 18
Jurnalele serverului web nu conțin date trimise în HTTP

antet, cum ar fi parametrii POST. Antetul HTTP poate conține valori
datele, deoarece majoritatea formularelor și parametrii lor sunt trimise de POST
solicitări. Aceasta apare ca o deficiență mare pentru fișierele jurnal ale serverului web.
Un server web poate acționa, de asemenea, ca un paravan de protecție pentru aplicații web (a se vedea
secțiunea anterioară). Modulul Apache mod_security [Încălcare
Security, 2007] permite, de exemplu, să stabilească reguli detaliate pe HTTP
date, exact ca pe un WAF. Desigur, astfel de reguli vor avea

acces la informațiile complete despre antetul HTTP, inclusiv POST
parametrii și poate permite înregistrarea suplimentară a acestor parametri
(acces cu succes sau refuzat).
aplicatie web
O aplicație web constă dintr-un cadru (PHP, ASP, J2EE,
etc.) care implementează logica afacerii. Se consideră că este

cea mai bună practică pentru efectuarea validării de intrare / ieșire în acest nivel. A
o politică puternică de validare a intrărilor va detecta malformații și rău intenționate
introduce și poate înregistra informații legate de securitate într-un fișier jurnal. The
aplicația are acces la traseul complet al utilizatorului la fiecare pas al unui utilizator
preluați (conectarea, efectuarea unui transfer, deconectarea etc.). A
jurnalizarea cuprinzătoare la nivelul aplicației permite
detectarea abuzului și a fraudei și permite reconstrucția completă a

pașii unui utilizator.
Sistem de detectare a intruziunilor în rețea (NIDS)
Un sistem de detectare a intruziunilor de rețea (NIDS) este plasat în

infrastructura de rețea de unde poate vedea traficul către și de la
aplicația web. De obicei, locuiește pe propria mașină și

analizează traficul web fără a atinge paravanele de protecție și
aplicația în sine. NIDS are o serie de dezavantaje față de un
WAF:
Roger Meyer 17
Pagina 19
● Dacă traficul HTTP este criptat SSL (HTTPS), NIDS

s-ar putea să nu decripteze traficul;
●O încărcătură mare de trafic poate face dificilă analiza

trafic de rețea în timp real;
● NIDS sunt concepute pentru a funcționa la nivel TCP / IP (strat OSI

3/4) și, prin urmare, poate să nu fie la fel de eficient pe stratul HTTP;
● Atacatorii ar putea folosi tehnici de evaziune IDS (HTTP,

codificare, fragmentare etc.) de care IDS nu este conștient.
Snort, cel mai puternic IDS open source, are peste 800 de reguli
(reguli ale comunității, lansat în 20070427) pentru detectarea unui web rău intenționat
trafic (peste 400 numai pentru PHP). Cu ajutorul preprocesoarelor
cum ar fi frag3 (defragmentare IP), stream4 (stateful

inspecție / reasamblare flux) și http_inspect (normalizare și
detectează
Amprentă traficul
cheie = AF19 HTTP
FA27 2F94 și FDB5
998D anomaliile protocolului)
DE3D F8B5
06E4 A169snort
4E46 încearcă
asamblați pachete și evitați tehnicile de evaziune IDS. Aceste obstacole

să
trebuie depășite înainte ca ceva să poată fi detectat.
Analiza jurnalelor vs. trafic complet
Fișierele jurnal conțin doar un set parțial de trafic complet

trecând prin rețea. În funcție de aplicația care scrie
jurnalele, aceasta poate fi o pistă completă de audit sau doar câteva date. The
următorul tabel prezintă cele mai semnificative diferențe între

analizarea fișierelor jurnal și a traficului complet.

Roger Meyer 18
Pagina 20
Avantaje Dezavantaje
Fișiere jurnal datele sunt ușor disponibile jurnalele conțin de obicei numai
de analizat (în o fracțiune din total

fișiere) date (ex. HTTP lipsă
Parametrii POST)
Trafic complet toate informațiile pot datele trebuie capturate

să fie analizate primul
datele ar trebui să fie
asamblat, defragmentat,
normalizat etc. (IP
pachete, fragmente IP)
s-ar putea fi dificil să

captează date (criptate
trafic, trafic intens
încărcare etc.)
Cel mai mare beneficiu al fișierelor jurnal este relativ simplu

disponibilitatea și analiza conținutului acestora. Servere web cum ar fi
Apache are înregistrarea activată în mod implicit. Aplicațiile fac de obicei

unele înregistrări pentru a asigura trasabilitatea acțiunilor lor. In timp ce
traficul complet oferă informații suplimentare, achiziționarea și
costurile de procesare depășesc de obicei beneficiile lor. Colecția de
traficul de rețea necesită a) vizibilitatea pachetelor și b) de obicei
hardware suplimentar. Urmărirea traficului poate fi realizată cu hub-uri,
Porturi SPAN, robinete sau dispozitive inline. Toate aceste dispozitive trebuie să fie
achiziționat, instalat și acceptat. Odată ce datele sunt colectate, acestea

trebuie procesat într-un format adecvat, astfel încât să poată fi
analizate. Abia acum traficul de rețea colectat este același
formular ca fișiere jurnal și este gata pentru a fi analizat. La sfarsit,
Roger Meyer 19
Pagina 21
fișierele jurnal oferă un proces ușor disponibil și ușor de procesat

posibilitatea de a face monitorizarea securității.
Următoarea secțiune discută cele două strategii de detectare

reguli statice și reguli dinamice.
4.1 Detecție bazată pe reguli (reguli statice)
Atacurile pot fi detectate prin două strategii diferite: regulă

bazate pe anomalii. Strategia bazată pe reguli definește statica
reguli care trebuie definite înainte ca analiza să poată fi făcută.
Acestea pot fi reguli simple, cum ar fi detectarea anumitor caractere

sau reguli mai complexe, cum ar fi atacurile de fixare a sesiunii.
Anomalirulele constau din reguli dinamice, acestea vor fi

discutată în secțiunea următoare.
Amprentă cheie = Regulile

AF19 FA27statice
suntFDB5
2F94 998D definite
DE3Do dată
F8B5 și rămân
06E4 A169aceleași
4E46 în timpul
faza de detectare. Acestea trebuie definite și create special
pentru fiecare aplicație. Regulile statice au cel mai mult sens pentru precunoscute
valori precum anumite caractere de intrare, o lungime fixă a
parametru sau o limită superioară a unei sume de transfer.
Regulile statice pot fi împărțite în două detecții

modele: modelul de securitate negativ și cel pozitiv.
4.1.1 Model de securitate negativ
Modelul de securitate negativ sau abordarea pe lista neagră are un

politica implicită de a permite totul. Aceasta înseamnă că totul este
permis să treacă, sau totul este considerat „normal”, acceptat

trafic. Politica (lista neagră sau baza de reguli) definește ce
nu este permis sau în termeni IDS ceea ce va fi marcat ca un atac.
Acest model este de obicei considerat cel mai ușor așa cum este
Roger Meyer 20
Pagina 22
mai ușor de implementat, totuși nu este o bună abordare de securitate

înţelept. Cel mai mare dezavantaj este că detectarea va fi doar
la fel de bună ca politica. Trebuie adoptat pentru noi descoperiri și
actualizat pentru a recunoaște noii vectori de atac. Unul dintre pozitive
Ideea este că produce foarte puține falsuri pozitive ca reguli
va căuta de obicei corzi de atac specifice, bine cunoscute sau
comportament.
Setul de reguli Snort este un exemplu de abordare pe lista neagră.
4.1.2 Model de securitate pozitivă
Modelul de securitate pozitiv este opusul negativului

model de securitate. Politica implicită aici este refuzarea tuturor, politica
va defini apoi ce este permis. Politica sau lista albă,
definește ceea ce este considerat „normal”, trafic bun. Această listă albă
poate fi definit automat într-o fază de învățare sau poate fi manual

definit. Este important ca faza de învățare să fie formată din
trafic legitim, deoarece orice altceva va fi considerat ca
rău intenționat.
Acest model este modalitatea preferată din punct de vedere al securității.

Falsele negative pot fi reduse la minimum, în timp ce falsele pozitive
ajuta la îmbunătățirea listei albe.
Firewall-urile sunt de obicei configurate în acest fel. Politica implicită
va fi negat. Pentru fiecare server / serviciu trebuie să existe un nou

intrarea pe lista albă pentru această mașină și port specific.
4.2 Detecție bazată pe anomalii (reguli dinamice)

Anomalirulele constau din reguli dinamice. După cum sugerează și numele,
aceste reguli nu sunt statice și nici nu sunt definite manual. In schimb,
regulile sunt definite printr-o fază de învățare. În această învățare
Roger Meyer 21
Pagina 23
fază, traficul bun este înregistrat ca „normal“. Este de cea mai mare
importanță, că acest trafic este „curat” și lipsit de atacuri, așa cum
aceasta va fi folosită ca bază de referință. De obicei, o simulare
mediul este folosit pentru astfel de teste. Scopul unei învățări
faza constă în definirea modului în care arată traficul „normal“, acceptat

în cele din urmă semnalizați traficul anormal, care nu arată
„Normal“ și trageți o alarmă. Abaterile de la acest set de reguli vor fi
marcat ca trafic anormal.
4.3 Detectarea OWASP Top Ten 2007
Acest capitol descrie modul în care poate fi OWASP Top Ten 2007
detectat. Detectarea se aplică numai datelor stocate pe web
fișiere jurnal aplicație. Acest set de date redus limitează detectarea
la datele disponibile, ceea ce desigur simplifică analiza

dar mai important îngustează detectarea. Fiecare vulnerabilitate

vacheie
Amprentă fi descris
= AF19pe scurt
FA27 și 998D
2F94 explicat
FDB5modul
DE3D în care
F8B5 poate
06E4 fi 4E46
A169 detectat
cu o mostră de expresie regulată.
4.3.1 A1 Cross Site Scripting (XSS)
Defectele XSS sunt în prezent defectul nr. 1 al lui Mitre's Common

Vulnerabilități și expuneri (CVE) [MITRE, 2007] site a
creștere considerabilă față de acum 12 luni. Vulnerabilități XSS
a cuprins unul din cinci dintre toate bug-urile raportate de CVE în 2006 [Christey,
2007].
Atacurile de cross site scripting funcționează prin încorporarea etichetelor de script în
Adrese URL / solicitări HTTP și atragerea utilizatorilor care nu bănuiesc să facă clic
, asigurându-se că javascriptul rău intenționat este executat pe

mașina victimei. Aceste atacuri stimulează încrederea dintre
utilizator și server și faptul că nu există intrare / ieșire
validare pe server pentru a respinge javascript sau alt cod activ
Roger Meyer 22
Pagina 24
personaje. Atacurile simple conțin etichete HTML precum <h1> sau

<script>. Un exemplu des folosit este <script> alert („XSS”) </script>.
O modalitate simplă este de a detecta astfel de etichete HTML. Următorul regulat
expresia recunoaște etichetele:
/ ((\% 3C) | <) ((\% 2F) | \ /) * [az09 \%] + ((\% 3E) |>) / ix
Explicaţie:
((\% 3C) | <) verificați dacă există unghiul de deschidere sau hexagonul
echivalent („3C”)
((\% 2F) | \ /) * linia directă pentru o etichetă de închidere sau hex
echivalent („2F”)
[az09 \%] + verificați dacă există șir alfanumeric în interiorul etichetei sau
reprezentarea hexagonală a acestora (suplimentar
procent caracter)
((\% 3E) |>) verificați dacă există unghiul de închidere sau hex
echivalent („3E”)
Modificatorii 'i' și 'x' (la sfârșitul regexului, după

bară de închidere '/') sunt utilizate pentru a se potrivi fără majuscule
sensibilitate și respectiv pentru a ignora spațiile albe.
Bineînțeles, acest lucru va detecta orice etichetă XML / HTML, inclusiv orice etichetă
contribuția legitimă a utilizatorului, așa cum se întâmplă de obicei într-un forum pe Internet și
poate duce la multe falsuri pozitive.
A fost un regex frumos pentru început. Din pacate,
javascript poate fi inclus în multe alte locuri și etichete. unu

locul popular este eticheta „img”, unde utilizatorii ar putea să poată seta
numele propriu al fișierului imagine (de exemplu, un avatar). „Src”
parametrul etichetei „img” va funcționa bine ca vector javascript.
Există mult mai multe etichete HTML, unde pot fi incluse javascript.

Exemple:
● <img src = "javascript: alert ('img src XSS')"> imaginea 1 </a>
Roger Meyer 23
Pagina 25
● <img src = "" onerror = "alert ('img onerror XSS')"> imagine

2 </a>
● <img
src = & # 106 & # 97 & # 118 & # 97 & # 115 & # 99 & # 114 & # 105 & # 112 & # 116 & # 58 & # 97 & #
108 & # 101 & # 114 & # 116 & # 40 & # 39 & # 88 & # 83 & # 83 & # 39 & # 41> imaginea 3 </a>
# javascript: alert ('XSS')
● <a href="javascript:alert('a href XSS')"> link </a>
● <body onload = "alert (String.fromCharCode (88,83,83))">
O abordare de bază pentru a detecta atacurile de mai sus ar fi căutarea

numele etichetei, de ex. img:
/ ((\% 3C) | <) ((\% 69) | i | (\% 49)) ((\% 6D) | m | (\% 4D)) ((\% 67) | g | ( \
% 47)) [^ \ n] + ((\% 3E) |>) / I
Explicaţie:
(\% 3C) | <) consolă unghiulară de deschidere sau echivalent hexagonal („3C”)
(\% 69) | i | (\% 49)) literele „img” în diferite combinații de
((\% 6D) | m | (\% 4D)) ASCII, sau echivalente hex majuscule sau minuscule
((\% 67) | g | (\% 47)
[^ \ n] + orice alt caracter decât o nouă linie care urmează
„<img”
(\% 3E) |>) parantez unghiular de închidere sau echivalent hexagonal („3E”)
O abordare mai reușită ar fi căutarea tuturor

expresii posibile care pot declanșa javascript sau alte active
cod. Iată o listă cu posibilele incluziuni de scripturi:
Etichete HTML:

● javascript, vbscript, expresie, applet, meta, xml,
clipire, legătură, stil, script, încorporare, obiect, iframe, cadru,
set de cadre, strat, strat, bgsound, titlu, bază
Roger Meyer 24
Pagina 26
Manipulatori de evenimente Javascript (extras):
● onabort, onactivate, onafterprint, onafterupdate,

onsubmit, onunload, ...
Să scriem un regex pentru a detecta unele dintre aceste cuvinte cheie:
/ (javascript | vbscript | expresie | applet | script | embed | obiect |

iframe | frame | frameset) / i
Explicaţie:
(javascript | Fiecare cuvânt cheie din paranteze va fi

vbscript | ...) asortat. Caracterul pipe ('|') denotă un OR.
Dar chiar și căutarea tuturor expresiilor de mai sus nu este

garanție pentru a găsi toate injecțiile XSS. Contextul codului
injecția este esența. Dacă injecția are loc în interiorul unui

parte a codului javascript, nu este nevoie de nici o etichetă sau una din
expresiile de mai sus, de obicei se poate insera doar cod javascript.
Acest tip de injecții XSS sunt foarte greu de detectat.
Detectarea atacurilor XSS din lumea reală

Pentru o analiză a lumii reale avem nevoie de jurnale de pe un server web.
Proiectul Honeynet a oferit obișnuit Provocări Honeynet
să analizeze atacurile și să le împărtășească descoperirile. Provocarea în
Scanarea 31 a fost de a analiza fișierele jurnal ale serverului web în căutarea semnelor
abuz [Honeynet Project Scan 31, 2004].
Fișierele jurnal din Scan 31 pot fi descărcate de pe

Site-ul web Honeynet Project. Analizând fișierul apache access_log
cu expresiile regulate de mai sus dă rezultate interesante.

Iată două exemple de cereri:
Roger Meyer 25
Pagina 27
217.160.165.173 [12 / mar / 2004: 22: 31: 12 0500]

"GET /foo.jsp?<SCRIPT>foo</SCRIPT>.jsp HTTP / 1.1" 200 578 ""
„Mozilla / 4.75 [ro] (X11, U; Nessus)”
217.160.165.173 [12 / mar / 2004: 22: 37: 17 0500] "GET / cgi

bin / cvslog.cgi? file = <SCRIPT> window.alert </SCRIPT> HTTP / 1.1 "403
302 "" "Mozilla / 4.75 [ro] (X11, U; Nessus)"
Acestea sunt două cereri de scanare Nessus, care încearcă să le găsească

scripturi vulnerabile la XSS. Conform HTTP
cod de stare, în prima cerere, web-ul a răspuns cu un
200 OK, ceea ce înseamnă că foo.jsp a fost acolo și a difuzat o pagină. Noi
totuși, nu știu dacă această pagină este vulnerabilă. Ar trebui să o facem
încercați manual această solicitare pentru a afla. A doua cerere
(cvslog.cgi) nu a avut succes, serverul a răspuns cu un 403
Răspuns interzis, ceea ce înseamnă că serverul web a refuzat

acces.
4.3.2 Defecțiuni la injecție A2
Injecția de cod poate fi orice tip de cod, cum ar fi SQL, LDAP, XPath,
Injectarea comenzilor XSLT, HTML, XML și OS. XSS (vezi A1) este de fapt
un subset de injecție HTML. Aici ne concentrăm pe cel mai mult
injecție predominantă, injecția SQL. Pentru injecții SQL la
munca, atacatorul trebuie să sară din instrucțiunea SQL originală.
Acest lucru se face, de obicei, prin singlequote (') sau doubledash
(). Citatul unic acționează ca un delimitator pentru o interogare SQL; the
doubledash este caracterul de comentariu din Oracle și MS SQL.
/ (\ ') | (\% 27) | (\\) | (#) | (\% 23) / ix

Explicaţie:
Roger Meyer 26
Pagina 28
(\ ') | (\% 27) citatul unic și versiunea sa codificată URL

(\\) dublul
(#) | (\% 23) semnul lirei și versiunea sa codificată URL
Mai întâi detectăm fie echivalentul hexagonal al single-ului

citat, citatul unic în sine sau prezența dublei.
Acestea sunt caractere SQL pentru MS SQL Server și Oracle, care
denotați începutul unui comentariu și tot ce urmează este

ignorat. În plus, dacă utilizați MySQL, trebuie să verificați
pentru prezența „#” sau a echivalentului său. Rețineți că da
nu trebuie să verifici echivalentul dublei,
deoarece nu este un metacaracter HTML și nu va fi codat
de către browser. De asemenea, dacă un atacator încearcă să modifice manual fișierul
doubledash la valoarea sa hexagonală de% 2D (folosind un proxy precum Ahile),
atacul de injecție SQL eșuează.
Regexul anterior eșuează atunci când nu există nici o singură citată

Amprentă cheie
nici = AF19în
o dublă FA27 2F94de
tiparul 998D FDB5
atac. EsteDE3D F8B5 injecția
posibilă 06E4 A169
chiar și fără citatul unic [Anley, 2002]. Să luăm asta

4E46
SQL
exemplu de instrucțiune SQL:
selectați valoare1, valoare_numerică2 din tabelul1 unde

numeric_value2 = user_input
Aici, un atacator poate executa o interogare SQL suplimentară, prin
furnizarea unei intrări precum:
7; selectați * din utilizatori
Modelul de detecție de mai sus ar putea fi ușor extins cu

punct și virgulă (';'). Din păcate, punctul și virgula este un lucru obișnuit
caracter în adrese URL. Exemplu:
POST /login.jsp ; jsessionid = HLQxtLQ13

Roger Meyer 27
Pagina 29
Detectarea ar putea fi restrânsă prin detectarea egalilor

caracter ('=') și căutați doar punct și virgulă în parametrii URL.
Intrările de utilizator rău intenționate ar putea arăta astfel:
POST /login.jsp?username=bill&password=1234;select * from

utilizatori
Să ne modificăm regexul anterior pentru a detecta acest tip de

atac.
/ ((\% 3D) | (=)) [^ \ n] * ((\% 27) | (\ ') | (\\) | (\% 3B) | (;)) / i
Explicaţie:
((\% 3D) | (=)) Semnul egal ('=') sau versiunea sa codificată URL
[^ \ n] * zero sau mai multe caractere neliniare
((\% 27) | (\ ') | Citatul unic, dublul sau semi
(\\) | (\% 3B) | colon sau versiunile lor codificate URL
(;))

Acest model caută semnul egal urmat de zero sau

mai multe caractere non-line și apoi o singură citată, o dublă linie
sau punct și virgulă.
Un alt vector tipic de atac este utilizarea cuvântului cheie SQL

'sau'. Un exemplu de atac SQL ar putea arăta ca 1 'sau' 2 '=' 2. De
desigur, există variații infinite ale acestui lucru, cum ar fi 1 'sau 1 <2.
Singura parte constantă este citatul unic urmat de cuvânt

'sau'. Să încercăm să scrie o expresie regulată pentru a detecta acest lucru
atac:
/ \ w * ((\% 27) | (\ ')) (\ s | \ + | \% 20) * ((\% 6F) | o | (\% 4F)) ((\% 72) | r | (\
% 52)) / ix

Roger Meyer 28
Pagina 30
Explicaţie:
\w* zero sau mai multe alfanumerice sau subliniate

personaje
(\ s | \ + | \% 20) * zero, unul sau mai multe spații albe sau HTTP-ul lor
echivalente codați
((\% 27) | (\ ')) citatul unic sau echivalentul său hexagonal
((\% 6F) | o | (\% 4F)) cuvântul „sau” cu combinații de superior și
((\% 72) | r | (\% 52)) echivalente hex minuscule
Pe lângă cuvântul cheie „sau”, există un alt cuvânt cheie SQL care
este frecvent utilizat în atacuri - cuvântul cheie UNION. UNION este folosit pentru a
combinați rezultatul din mai multe instrucțiuni SELECT într-o singură

setul de rezultate. Atacatorii îl pot folosi pentru a combina o declarație selectată
dat de aplicație cu un atacator specificat selectați
afirmație. Acest lucru permite unui atacator citit tabele diferite fata
una specificată în declarație de aplicație. Să ne extindem
regexul anterior cu câteva cuvinte cheie SQL mai interesante.

/ ((\% 27) | (\ ')) (selectați | unire | inserare | actualizare | ștergere | înlocuire |
trunchia) / ix
Explicaţie:
(\% 27) | (\ ') citatul unic și echivalentul său hexagonal

(Selectați | Union | cuvintele cheie SQL
inserați | actualizare |
șterge | înlocui |
trunchia)
În cazul în care baza de date backend rulează pe MS SQL, există unele

în special procedurile stocate periculoase, pe care atacatorul le va face
încearcă să exploatezi. Aceste proceduri încep cu literele „sp” sau

„xp” respectiv. Una dintre procedurile infame este
Procedura extinsă 'xp_cmdshell', care permite executarea

Shell Windows comenzi prin SQL Server. Drepturile de acces
cu care se vor executa aceste comenzi sunt cele ale
Roger Meyer 29
Pagina 31
cont cu care SQL Server rulează de obicei Sistem local.
/ exec (\ s | \ +) + (s | x) p \ w + / ix
Explicaţie:
exec cuvântul cheie necesar pentru a rula stocarea sau

procedură extinsă
(\ s | \ +) + unul sau mai multe spații albe sau codurile lor HTTP
echivalente
(s | x) p literele 'sp' sau 'xp' pentru a identifica stocate sau
proceduri extinse respectiv
\w+ unul sau mai multe alfanumerice sau subliniate
caractere pentru a completa numele procedurii
Alte defecte ale injecției, cum ar fi injecțiile de comandă ale sistemului de operare, sunt puțin
mai greu de detectat deoarece nu există nici un model predefinit
disponibil. Deși există câteva personaje speciale precum
simbolul țevii ('|') care este rar folosit într-o adresă URL:
/ (\ ||% 00 | system \ (| eval \ (| `| \\) / i
Explicaţie:
\| Simbolul țevii: utilizat în comenzi pentru „pipă”

stdout dintr-un program în stdin al altui.
Acest lucru poate fi abuzat pentru a executa o altă comandă.
% 00 Caracterul NUL (zecimal și hexazecimal 0) este
utilizat în programele bazate pe C / C ++ ca șir
delimitator (ultimul element într-o matrice char). Aceasta
poate fi uneori abuzat pentru a păcăli acele programe
să trateze acest personaj ca pe ultimul caracter și
ignorați orice alte caractere. Alte limbi
cum ar fi Perl sau PHP, vor citi cu bucurie pe lângă NUL
caracter și executați codul.
sistem\( System () este o funcție în limbaje de programare
cum ar fi Perl și PHP care execută un extern
program și afișează ieșirea.

eval ( Eval () este o funcție în PHP, Perl și altele
limbi care evaluează un șir ca
PHP / Perl / ... cod.
Roger Meyer 30
Pagina 32
` Operatorul backtick este similar cu sistemul ()

funcție prin aceea că execută o externă
program.
\\ Backlash-ul este folosit pentru a scăpa de caractere. Dacă
reacția care scapă poate fi evadată, atacatori
poate sări din secvența evadată.
Detectarea atacurilor de injecție din lumea reală
Analizăm din nou Scan 31 din Honeynet Project
Provocare [Honeynet Project Scan 31, 2004]. Iată două
cereri de exemplu, detectate cu expresiile regulate de mai sus:
81.171.1.165 [13 / Mar / 2004: 10: 46: 43 0500] „HEAD

? Http: //www.sweetgeorgia.com/cgibin/af.cgi _browser_out = |
echo; id; exit | HTTP / 1.0 "200 0" http://www.sweetgeorgia.com/cgi
bin / af.cgi? _browser_out = | echo; id; exit | "" Mozilla / 4.0

(compatibil; MSIE 6.0; Windows NT 5.1) "
66.138.147.49 [13 / Mar / 2004: 13: 33: 06 0500] "GET
http://login.korea.yahoo.com/config/login?.redir_from=PROFILES ?.
& login = &. tries = 1 & .src = jpg & .last = & promo = &. intl = us & .bypass = &. partn
er = &. chkP = Y & .done = http: //jpager.yahoo.com/jpager/pager2.shtml&lo
gin = blood`1234567890 & passwd = parola HTTP / 1.0 "200 566" "" "
Prima cerere încearcă să execute comenzi ale sistemului de operare. The

variabila „_browser_out” conține un simbol de țeavă, urmat de Unix
comenzi de sistem ('| echo; id; exit |').
A doua cerere apelează o funcție de autentificare. În conectare sale

numele (parametrul „autentificare”) este un simbol bifat înapoi

('sânge`1234567890'). Acest lucru ar putea fi un simplu atac brute force
sau un test cu privire la modul în care aplicația gestionează simbolul tick din spate.
Roger Meyer 31
Pagina 33
4.3.3 Executarea fișierelor rău intenționate A3
Aplicațiile care permit utilizatorului să furnizeze un nume de fișier, sau

o parte a unui nume de fișier este adesea vulnerabilă dacă intrarea nu este
validat atent. Permiterea atacator pentru a manipula
numele fișierului poate determina aplicația să execute un program de sistem sau
o adresă URL externă.
În trecut, PHP a fost foarte des criticat pentru această posibilitate
pentru a permite adresele URL să includă și să solicite declarații. Este cauza

pentru cele mai periculoase vulnerabilități din aplicațiile PHP:
adesea numit URL la distanță include vulnerabilități. Următoarele
Instrucțiunea include va include și va executa tot ce a fost postat
server-ul:
includeți „php: // input”;
Amprentă cheie = Următoarea declarație

AF19 FA27 2F94 include
998D FDB5 DE3Dva include
F8B5 și va4E46
06E4 A169 executa

încărcare utilă codificată base64. Aici acesta este doar phpinfo ():
includeți „date:; base64, PD9waHAgcGhwaW5mbygpOz8 +”;
Să încercăm mai întâi să prindem incluziunile de fișiere la distanță. În cazul în care o

fișierul este menționat pe o mașină la distanță, va exista un protocol
și o cale, cum ar fi http://www.example.com/bad.inc. Putem încerca
detectați acești specificatori de protocol:
/ (https? | ftp | php | data): / i
Explicaţie:
(https? | ftp | php | protocoalele http (s), ftp, php și date

date) urmat de colon

Aplicațiile care permit încărcarea fișierelor au supliment
Roger Meyer 32
Pagina 34
riscul introducerii codului executabil în aplicație.

Cu toate acestea, fișierul jurnal va conține doar scriptul, unde se află fișierul
va fi încărcat pe (de ex. POST /upload.php HTTP / 1.1). Continutul
a fișierului este vizibilă numai în aplicație.
4.3.4 Referință directă nesigură a obiectului A4
Aplicațiile expun adesea obiecte interne, făcându-le

accesibil prin intermediul parametrilor. Când aceste obiecte sunt expuse,
atacatorul poate manipula obiecte neautorizate, dacă are acces corect
comenzile nu sunt la locul lor.
Obiectele interne pot include:
● Fișiere sau directoare
● adrese URL
● Cheile
bazei de date, cum ar fi acct_no, group_id etc.
● Alte nume de obiecte ale bazei de date, cum ar fi numele tabelului
Fișierele pot fi recunoscute după numele sau finalul lor. Mai ales
fișierele periculoase pot fi / etc / passwd, / etc / shadow sau cmd.exe.
Directoarele pot fi parcurse folosind atacul dotdotslash
(../), sau traversarea căii.
/(\.|(%|%25)2E)(\.|(%|%25)2E)(\/|(%|%25)2F|\\|(%|%25)5C)/i
Explicaţie:
(\. | (% |% 25) 2E) Două puncte și echivalentele codate URL ale acestora,
(\. | (% |% 25) 2E) inclusiv codificarea hexagonală dublu procentuală.

(\ / | (% |
% 25) 2F | \\ | (% |
% 25) 5C)
slash și backslash (și codul URL al acestora
echivalente), ca separator de directoare poate fi
"\" dar deasemenea "/"
Roger Meyer 33
Pagina 35
În plus, solicitările codificate pot fi combinate în multe

căi diferite. Câteva exemple de codificare URL și URL dublu
codificare:
Varianta de codificare Reprezentare
% 2e% 2e% 2f ../ (% 2e: punct;% 2f: bară)
% 2e% 2e / ../
..% 2f ../
% 2e% 2e% 5c .. \ (% 5c: bară inversă)
% 2e% 2e \ .. \
..% 5c .. \
% 252e% 252e% 255c .. \ (Acesta este un procent dublu

codare hexagonală:% 25 reprezintă
un procent de caractere)
..% 255c .. \ (încă un procent dublu

codificare hexagonală)
..% c0% af ../ (codare UTF8)
..% c1% 9c .. \ (codare UTF8)
Înregistrările bazei de date sunt de obicei referite de un parametru URL

cum ar fi DocumentID, AccountID, StatementID sau pur și simplu id. Dacă aceia
tastele sunt numai numerice, se poate căuta non-numeric
argumente.

Aplicațiile web folosesc adesea numărul de cont ca principal
cheie. Prin urmare, numărul de cont poate fi manipulat direct într-un
Roger Meyer 34
Pagina 36
câmp parametru. Atacatorii ar încerca de obicei să parcurgă toate

(sau unele) dintre numerele de cont posibile, încercând să găsească valabile
conturi de utilizator. Acest lucru poate fi detectat prin înregistrarea adreselor IP
și valorile parametrilor. Dacă o singură adresă IP încearcă mai mult decât un
o anumită cantitate de numere de cont, se întâmplă un atac. (vedea
de asemenea, A7 Broken Authentication și Session Management)
Detectarea atacurilor de traversare a directorului din lumea reală
Scanează 31 din Honeynet Project Challenge [Honeynet

Project Scan 31, 2004] ne va servi din nou ca exemplu pentru un
atac de traversare a directorului din lumea reală:
68.48.142.117 [09 / mar / 2004: 22: 29: 43 0500]

„GET /scripts/..%255c../winnt/system32/cmd.exe?/c+dir HTTP / 1.0”
200 566 "" ""

„% 255c” este o codificare hexagonală de două procente. „% 25”
se rezolvă la un caracter procentual („%”), rezultatul „% 5c”
se rezolvă la o bară inversă ('\'). Solicitarea încearcă să acceseze fișierul
programul cmd.exe, shell-ul de comandă Windows pentru a executa „dir”
comanda (listează toate fișierele dintr-un director). Această cerere este foarte
comun pentru viermele Nimda. Nimda folosește Unicode Web Traversal
exploatați pentru a ataca serverele web Microsoft IIS neperfectate.
4.3.5 A5 Cross Site Request Forgery (CSRF)
Atacurile de falsificare a cererilor între site-uri sunt probabil cele mai multe
răspândiți atacul în aplicațiile web astăzi. Profită de unul
dintre cele mai elementare caracteristici HTML - link-ul. Orice proces cu un

o astfel de cerere este vulnerabilă:
https://www.example.com/transfer.php?amount=100&toAcct=12345
Roger Meyer 35
Pagina 37
Practic, fiecare aplicație ale cărei cereri se bazează numai pe

acreditări trimise automat, cum ar fi un cookie de sesiune
vulnerabil.
Pentru a exploata o vulnerabilitate CSRF, un atacator ar putea posta

după un forum:
<img src = ”https://www.example.com/trx.php?

amt = 100 & toAcct = 1234 ” width = ”0” height = ”0”>
Browserul va încerca să încarce lățimea zero (adică invizibil)

imagine făcând o solicitare la adresa URL specificată. Nu este
important ca adresa URL a imaginii să nu se refere la o imagine adecvată,
solicitarea va fi trimisă oricum (cu condiția ca browserul să nu fie dezactivat
pentru a descărca imagini).
Cum poate fi detectat acest lucru într-un fișier jurnal? O abordare ar fi
pentru
Amprentă cheie =a AF19
măsura diferența
FA27 înFDB5
2F94 998D timp DE3D
a solicitărilor
F8B5 06E4unui
A169utilizator.
4E46
nu a fost introdus de utilizator timp de câteva minute și apoi brusc unele

În cazul în care există
cererile de transfer vin, ar putea fi un indicator care

această cerere a fost declanșată de ceva / altcineva. Ar fi
un mod predispus la erori, deoarece ar trebui să definim un anumit timp
limite, care vor varia de la utilizator la utilizator.
O abordare mai bună este utilizarea indicatului. The

„Ținta” (sic) este un antet de solicitare HTTP care va fi conectat
formatul jurnal combinat. Primul indică ultima adresă URL, care
legat de solicitarea actuală. În cazul unui CSRF, această adresă URL va fi
site-ul atacatorilor. Să facem un exemplu: un atacator pregătește un
site-ul web pe următoarea adresă URL:

http://www.attacker.com/freestuff.php
Atacatorul păcălește un utilizator legitim - care este conectat
Roger Meyer 36
Pagina 38
aplicația sa bancară online (https://www.bank.com/) pentru a naviga

site-ul său pregătit. Acest site conține un atac XSRF care face un
transfer pe aplicația bancară online a utilizatorului. Fișierul jurnal activat
aplicația bancară ar arăta cam așa:
192.168.4.6 [10 / Oct / 2007: 13: 55: 36 0700] "GET /trx.php?

amt = 100 & toAcct = 12345 HTTP / 1.0 "200 4926
"http://www.attacker.com/freestuff.php" "Mozilla / 4.0 (compatibil;
MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)“
Două câmpuri sunt importante aici, adresa URL solicitată (/trx.php?

amt = 100 & toAcct = 12345) și primul
(„http://www.attacker.com/freestuff.php”). De obicei, rezultatul este
o adresă URL de pe același site (www.bank.com). Iată un exemplu de perl
fragment, cum ar putea fi detectat acest lucru:
# presupunând că $ Rând este setat cu, bine, Rând

if (($ Rhine ne '') &&
($ Începe! ~
/^https?:\/\/www.bank.com\/(login|overview|trx)\.jsp/)
){
# gestionează atacul XSRF
print („Atac XSRF: $ Întâlnire \ n”);

}
4.3.6 Scurgerea informațiilor A6 și gestionarea necorespunzătoare a erorilor
scurgere de informații se întâmplă de obicei în pagini de eroare care dau

îndepărtează prea multe informații. Mesajele de eroare pot conține valori
date cum ar fi dacă există un nume de utilizator pe sistem, căile aplicației,
informații despre server și fișiere de configurare. Pagini de eroare pot fi

a recunoscut cu codul de stare threedigit HTTP, care este conectat
pentru fiecare cerere. Aceste coduri de stare HTTP sunt utilizate în principal pentru
monitorizarea serverului și scopuri de depanare. Le putem analiza
Roger Meyer 37
Pagina 39
pentru a detecta atacuri precum enumerarea numelui de utilizator sau o cantitate anormală
a cererilor de eroare. Iată o prezentare generală a codurilor de stare HTTP:
Cod de stare Sens
1XX Informativ
2XX De succes
3XX Redirecționare
4XX Eroare client
5XX Eroare de server
În general, toate codurile de eroare> = 400 indică unele grave

Amprentă cheie =șiAF19
eroare FA27 analizat.
ar trebui 2F94 998DUnele
FDB5 DE3D
coduriF8B5 06E4 A169
de eroare 4E46 404
precum
(Not Found) sunt evident foarte frecvente. Cu toate acestea, pot fi la fel de
interesant ca ceilalți dacă dau (prea) multe informații.
4.3.7 A7 Autentificare defectă și gestionarea sesiunii
Cele mai multe aplicații pune în aplicare propria lor autentificare,

gestionarea și expirarea parolei și, prin urmare, nu sunt ușor
detectabil în fișierele jurnal ale serverului web. Există câteva elemente de bază
principiile, totuși, cum nu ar trebui să fie implementat. Sunt două
principii notabile care sunt vizibile în fișierele jurnal:
● Nu acceptați identificatori de sesiune noi, presetați sau nevalizi

din adresa URL sau din cerere. Aceasta se numește sesiune

atac de fixare;
● Nu expuneți niciun identificator de sesiune sau nici o parte din
Roger Meyer 38
Pagina 40
acreditări valide în URL-uri sau jurnale (fără rescriere sesiune sau

stocarea parolei utilizatorului în fișiere jurnal).
În general, un șir de interogare URL nu trebuie utilizat pentru niciunul

date sensibile precum ID-uri de sesiune, informații despre utilizator / sesiune, utilizator
numele, parolele etc. URL-urile sunt stocate în cache-ul browserului și
sunt conectate în proxy-uri web și stocate în cache-ul proxy-ului. Dacă
ID-urile de sesiune sunt stocate în cache de un proxy, ar putea fi posibil ca altele
utilizatorii vor putea accesa acest cont de utilizatori.
Exemple:
https://www.example.net/login?userid=bill&password=1234
https://www.exampl.net/doSomething?varA=123;jsessionid=1234
Numele parametrilor sunt specifice aplicației, dar sunt ușor
identificabil:
/login\.jsp.*\?.*(userId|password)=./ 8, Autorul își păstrează drepturile

/;jsessionid=./
Explicaţie:
login \ .jsp. * \?. * Scriptul login.jsp urmat de un semn de întrebare

(userId | și fie parametrul userId sau parola.
parola) =.
; jsessionid =. Căutați parametrul jsessionid în URL.
4.3.8 A8 Stocare criptografică nesigură
Stocarea criptografică nesigură nu este detectabilă cu

instrumente automate de scanare a vulnerabilităților. De asemenea, nu există nicio urmă în

serverul web înregistrează modul în care sunt stocate datele sensibile.
Roger Meyer 39
Pagina 41
4.3.9 A9 Comunicări nesigure
Fiecare aplicație HTTP folosește o formă de autentificare care

trebuie transmis prin Internet. Pentru a asigura siguranța și
transmiterea confidențială pe un mediu nesigur precum
Internet, tot traficul de autentificare trebuie să treacă prin SSL, nu
doar cererea de autentificare efectivă.
Cum putem verifica dacă aplicația criptează corect toate
autentificare și comunicări sensibile? Serverele web oferă

suport pentru înregistrarea oricărui aspect al cererii legat de SSL. Apache,
de exemplu, permite cu directiva CustomLog să se înregistreze
informații despre parametrii SSL. Iată câteva interesante
directive:
Nume directivă Descriere
% {SSL_PROTOCOL} x
versiunea protocolului
% {SSL_CIPHER} x apartamente cifrate
% {SSL_CIPHER_USEKEYSIZE} x dimensiunea cheii
Este recomandat să înregistrați cel puțin versiunea protocolului și

suite cifrate alese:
CustomLog logs / ssl_request_log \

„% t% h% {HTTPS} x% {SSL_PROTOCOL} x% {SSL_CIPHER} x
% {SSL_CIPHER_USEKEYSIZE} x% {SSL_CLIENT_VERIFY} x
\ "% r \"% b "

Exemplu de intrare în jurnal:
Roger Meyer 40
Pagina 42
2007.12.0404: 43: 30 10.3.78.36 pe SSLv3 RC4MD5 128 NONE "GET

/index.html HTTP / 1.1 "13552
Această solicitare utilizează o conexiune SSLv3 pe 128 biți cu un RC4

Suită de cifrare MD5.
Pentru a vă asigura că toate cererile HTTP sunt criptate SSL, SSL
fișierul jurnal de solicitări poate fi monitorizat pentru solicitări necriptate.

Exemplu:
2007.12.0420: 09: 49 10.73.60.22 reducere „GET /”
Dacă serverul web acceptă doar conexiuni SSL prin port TCP
443 în primul rând, atunci ar trebui să se vadă doar criptat
conexiuni în fișierul jurnal. Este întotdeauna o idee bună de verificat
deşi.

4.3.10
Amprentă A10
cheie = Eșecul
AF19 FA27restricționării
2F94 998D FDB5 accesului la URL
DE3D F8B5 06E4 A169 4E46
Când aplicația nu reușește să restricționeze accesul la

URL-uri administrative, atacatorul poate accesa astfel de pagini tastând
în adresa URL din browser. Acest lucru este surprinzător de comun, pentru
exemplu:
add_account_form.php verifică accesul administratorului înainte

afișarea formularului.
Acest formular apoi postează în add_acct.php care face treaba, dar

nu verifică privilegiile de administrator!
Un control de acces URL coerent trebuie proiectat cu atenție.

Pentru detectarea unor astfel de atacuri, nu există o metodă infailibilă

disponibil. Încă o dată, verificarea rezultatului poate fi utilă. daca tu
pentru unii, vedeți alte site-uri web decât cel local
pagină privilegiată, acest lucru ar putea fi suspect. Se poate monitoriza, de asemenea
Roger Meyer 41
Pagina 43
fișierele care nu ar trebui să fie accesate precum includ și

fișiere bibliotecă.
5. Concluzie
Există două detecții de atac fundamental diferite

metode - detecție bazată pe reguli (reguli statice) și bazată pe anomalii
detectare (reguli dinamice). Analiza jurnalului serverului web este bazată pe reguli
modul de detectare care se concentrează pe atacurile web vizibile
în fișierele de jurnal implicite ale serverului web, cum ar fi Apache sau IIS.
Există mai multe obstacole care trebuie depășite pentru a fi detectate

atacuri în fișiere jurnal. În primul rând, vectorii de atac trebuie cunoscuți
pentru a face reguli de detectare. Prin urmare, este important să știți cât mai mulți
diferite variante de atac posibil. Un alt obstacol este
diferite variante și standarde de codificare. Standardele sunt importante

dar
Amprentă uneori
cheie poate
= AF19 FA27fi2F94
dificil
998DpeFDB5
măsură ce F8B5
DE3D diferiți
06E4furnizori le implementează
A169 4E46
putin diferit. Fiecare server web acceptă, de asemenea, diferite

standarde, care trebuie luate în considerare.
Odată studiate diferitele idiosincrazii, este bine cunoscut

atacurile pot fi ușor detectate și eventual reacționate. O fântână
set definit de expresii regulate permit identificarea

multe dintre cele mai importante securități ale aplicațiilor web OWASP Top Ten
defecte.
6 Referințe
The Honeynet Project & Research Alliance (2007). Cunoaște-ți

Inamic: amenințări ale aplicațiilor web.

http://www.honeynet.org/papers/webapp/
Friedl, J. (1997). Stăpânirea expresiilor regulate. Sebastopol,
Roger Meyer 42
Pagina 44
Referințe Detectarea atacurilor pe aplicații web
CA: O'Reilly Media, Inc.
Kruegel, C., Vigna, G. (2003). Detectarea anomaliilor bazate pe web

Atacuri. New York, NY: Asociația pentru mașini de calcul.
Mookhey, K. K., Burghate N. (2004). Detectarea SQL

Atacuri de injecție și scripturi încrucișate.
http://www.blackhat.com/presentations/bhusa04/bhus04
mookhey / old / bhus04mookhey_whitepaper.pdf
Anley, C. (2002). Injecție SQL avansată în SQL Server

Aplicații.
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
Roelker J. D., (2003). HTTP IDS Evasions Revisited.

http://docs.idsresearch.org/http_ids_evasions.pdf
Consorțiul de securitate a aplicațiilor web, (2006). Aplicatie web

Criterii de evaluare firewall.
http://www.webappsec.org/projects/wafec/
Institutul SANS, (2007). SANS Top20 Internet Security Attack

Ținte. http://www.sans.org/top20/
Revista SC, (2007). Aplicația web exploatează cea mai mare țintă de hacking
în 2007. http://www.securecomputing.net.au/print.aspx?CIID=72867
Săptămâna IT, (2006). Aplicațiile web sunt ținte ușoare.

http://www.vnunet.com/articles/print/2148638
Fortify Software Inc., (2006). Aplicații web sub atac.

http://www.fortifysoftware.com/reports/threatreport.jsp

Open Web Application Security Project (OWASP), (2007).
Proiect OWASP Top Ten.
Roger Meyer 43
Pagina 45
Referințe Detectarea atacurilor pe aplicații web
http://www.owasp.org/index.php/OWASP_Top_Ten_Project
Server HTTP Apache, (2007). Formatul jurnalului combinat.
http://httpd.apache.org/docs/1.3/logs.html#combined
Interconectarea sistemelor deschise, (1994). Sistemele deschise

Mod de referință de bază pentru interconectare (standardul ISO 74981: 1994)
http://en.wikipedia.org/wiki/OSI_model
Breach Security (2007). ModSecurity pentru Apache.

http://www.modsecurity.org/
Corporația MITRE (2007). Vulnerabilități comune și

Expuneri (CVE®). http://cve.mitre.org/about/
Christey, S., Martin, R. A., (2007). Tipul de vulnerabilitate

Distribuții în CVE. http://cve.mitre.org/docs/vulntrends/

The Honeynet Project, (2004). Scanează 31 Descoperă cum
OpenProxy este abuzat. http://www.honeynet.org/scans/scan31/
Fielding și colab., (1999). RFC 2616: Transfer hipertext
Protocol - HTTP / 1.1. http://www.ietf.org/rfc/rfc2616.txt
Ellacoya Networks, Inc. (2007). Comunicat de presă: Ellacoya Data

Afișează traficul web care depășește PeertoPeer (P2P) ca fiind cel mai mare
Procentul lățimii de bandă din rețea
http://www.ellacoya.com/news/pdf/2007/NXTcommEllacoyaMediaAlert.pd
f
Greenemeier L., (2006). InformationWeek: Web App Hack

Incidentele apar pe măsură ce întreprinderile se acoperă

http://www.informationweek.com/industries/showArticle.jhtml?
articolID = 185300842
Roger Meyer 44

Detectarea Atacurilor Asupra Aplicațiilor Web Din Fișierele Jurnal

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Detectarea Atacurilor Asupra Aplicațiilor Web Din Fișierele Jurnal

Încărcat de

Drepturi de autor:

Formate disponibile

13.10.

Copyright SANS Institute 2021. Autorul își păstrează drepturile depline.

Detectarea atacurilor pe aplicații web

8, Autorul își păstrează drepturile

Certificare GCIA Gold

Autor: Roger Meyer

Consilier: Carlos Cid

Acceptat: 26 ianuarie 2008

© SANS Institute 200

Detectarea atacurilor pe aplicații web

1 Rezumat ................................................ ...... 3

8, Autorul își păstrează drepturile

© SANS Institute 200

Abstract Detectarea atacurilor pe aplicații web

Traficul web (Hypertext Transfer Protocol, HTTP) a depășit

atacuri de rețea, deoarece amenință să fure clienți critici,

Trecerea tot mai mare către aplicațiile web se deschide nouă

Măsurile preventive (cum ar fi regulile Firewall pentru aplicații web) sunt

8, Autorul își păstrează drepturile

Această lucrare explică modul de detectare a celui mai critic web

© SANS Institute 200

Introducere Detectarea atacurilor pe aplicații web

Utilizarea internetului și aplicațiile online se confruntă

asociată cu protejarea informațiilor online a crescut

SANS Top20 Internet Security Attack Targets (Anual 2007

Aplicații. Câteva exemple de aplicații web sunt Conținut

Sisteme de management (CMS), Wikis, portaluri, panouri, magazine,

Acest lucru a făcut din detectarea și prevenirea acestor activități un top

© SANS Institute 200

● Este posibil să nu existe NIDS (greu de implementat; o altă zonă de

Introducere Detectarea atacurilor pe aplicații web

● Încărcarea mare de trafic face dificilă analiza rețelei

● NIDS sunt concepute pentru a funcționa la nivelul TCP / IP, și astfel

● tehnici de evaziune IDS (HTTP, codificare,

Analiza traficului web din fișierele jurnal are unele avantaje

diferențele vor fi explorate în capitolul ' 4 . Detectare

3 Atacuri pe aplicații web

Atacurile asupra aplicațiilor web sunt în continuă schimbare. A

● Roboții sunt folosiți în mai mult de jumătate din atacurile împotriva

● Atacatorii găsesc aplicații web defecte folosind

● Atacurile direcționate sunt din ce în ce mai sofisticate; și

Tendințe similare au fost găsite de [KYE: Web Application

© SANS Institute 200

Atacuri pe aplicații web Detectarea atacurilor pe aplicații web

dezvoltatori, designeri, arhitecți și organizații despre

vom intra în detalii despre cum să detectăm aceste atacuri.

Actualizarea din 2007 a adus câteva vulnerabilități noi, cum ar fi

Atacatorii vizează aplicații web cu diferite

8, Autorul își păstrează drepturile

(Top 10) atacurile vizează aplicația web în sine. Luând

3.1 Fișiere jurnal server web

Serverele web standard precum Apache și IIS generează jurnalizare

© SANS Institute 200

Atacuri pe aplicații web Detectarea atacurilor pe aplicații web

gazdă identitate identificator date cerere stare octeți

Dacă un simbol nu are o valoare, atunci acesta este reprezentat de un

● gazdă: numele de domeniu complet calificat al clientului sau

● ident: Dacă directiva IdentityCheck este activată și

● autentificator: dacă adresa URL solicitată a necesitat un succes

● data: data și ora solicitării.

● status: Codul de stare HTTP cu trei cifre returnat la

● octeți: numărul de octeți din obiectul returnat la

O cerere poate conține date suplimentare, cum ar fi rezultatul și