Puncte:0

NginX: cum să rescrieți corpul răspunsului și anteturile?

drapel in

Context

Am o colecție de pagini HTML statice (~10k pagini) generate de o aplicație asupra căreia nu am control. Aceste pagini sunt servite de NginX de la a Locație bloc.

Paginile pot conține date sensibile. Aș dori să pot bloca afișarea paginii în funcție de identitatea utilizatorului și de „steaguri” din pagină.

Aceste steaguri pot fi implementate de către a <meta name=keyword content="flag1 flag2 flagn"> element. Când un astfel de element este prezent, „acreditările” ar trebui verificate.

Ideea mea este să scanez răspunsul la cerere înainte de a-l lăsa înapoi utilizatorului. Pentru asta am nevoie

  • o modalitate de a transmite răspunsul complet (antet + corp) unui cod personalizat, astfel încât elementul <head> să poată fi analizat Dacă nu există indicatori, răspunsul este returnat nemodificat
    Dacă există steaguri și utilizatorul nu are acreditări, i se cere să se identifice
    Dacă există steaguri și utilizatorul are dreptul de a vedea, răspunsul este returnat nemodificat
    Dacă există indicatoare și utilizatorul nu are dreptul de a vedea, este returnată o pagină de eroare în locul răspunsului


    În cele din urmă, steagul <meta> elementul este șters pentru a evita scurgerile de indicii de filtru.

  • un mod de a transmite acestui cod de utilizator informații despre acreditările curente (numele utilizatorului, valoarea provocării, orice informații utile, cum ar fi ștampila de identificare, â¦)

Codul utilizatorului s-ar baza pe o „bază de date” (acest termen nu implică neapărat utilizarea unui adevărat motor DB) care conține privilegii de utilizator și va implementa o funcție de timeout.

Codul utilizatorului poate fi implementat ca script FastCGI? Dacă da, care sunt directivele pentru a-i transmite răspunsul complet?

Procesele preliminare

În prezent, identificarea utilizatorului nu poate fi condiționată: când auth_basic este activat în a Locație, utilizatorii trebuie să se identifice, chiar și pentru a accesa pagini publice. Pot atenua acest lucru având un utilizator/oaspeți/parolă, dar nu pot avea o pagină de avertizare înainte de a solicita acreditările.

Deci, autentificarea este întotdeauna necesară. Ulterior, an Autorizare: de bază some_hash antetul este trimis împreună cu cererea. Acest hash trebuie să fie capturat atunci când are loc autentificarea pentru accesul viitor la proprietățile privilegiate ale utilizatorilor.

Cum pot face asta?

Sunt conștient de faptul că, în starea actuală, această specificație nu oferă deloc securitate reală (vulnerabil la atacuri reluate printre altele). Vreau să creez o dovadă a conceptului înainte de a merge mai departe. Scopul meu are sens?

Există o modalitate mai simplă de a o gestiona? XSLT? (deși acreditările curente ale utilizatorului trebuie introduse în modele)

djdomi avatar
drapel za
chiar dacă întrebarea este bună, cred că nu este potrivită pentru serverfault.com, cred că site-ul de dezvoltare web cu care nu sunt familiarizat s-ar potrivi mai bine pentru tine
Puncte:1
drapel us

Cred că singura modalitate de a implementa acest lucru este utilizarea unui controler front-end care verifică cerințele logice de acces și apoi trimite fișierele HTML de pe disc.

Nu ai folosi niciuna auth directive de la nginx. Procesul de autentificare va fi gestionat de controlerul front-end.

Controlerul front-end poate fi implementat în mai multe moduri, de exemplu aplicația Node.JS, PHP, Ruby on Rails și Python.

ajlittoz avatar
drapel in
Iată ce a sugerat un prieten: gestionarea cererii printr-un „script” (Perl, Python, C, â¦) care preia pagina statică, decide dacă sunt necesare acreditări și returnează o „pagină” (fie pagina solicitată, fie o 401 pagini). Sper că returnarea codului 401 este suficientă pentru a declanșa dialogul de identificare a browserului care va trimite un antet „Autentificare:”. Acest antet va fi folosit pentru a stoca informații „în direct” pe server și alte anteturi „Autentificare:” pot fi ignorate. Totul se rezumă la trimiterea înapoi a unui cookie opac unic pentru solicitările ulterioare.
drapel us
Da, asta este abordarea. Și codul de stare HTTP yesm 401 declanșează o fereastră de autentificare în browser.
ajlittoz avatar
drapel in
Am făcut un test: trimit un antet `Stare: 401 Neautorizat` fără sarcină utilă (dar trimiterea unui bloc `` complet nu face nicio diferență) și acest lucru nu declanșează dialogul de autentificare în browser. Ce-ar trebui sa fac atunci?
ajlittoz avatar
drapel in
Pentru a declanșa solicitarea de autentificare, trimiteți antetul „WWW-Authenticate: xxx”.
ajlittoz avatar
drapel in
Dar `xxx` trebuie să fie `de bază` pentru a avea un efect, iar NginX interceptează în mod evident autentificarea deoarece cererea cu antetul `Authentication:` nu ajunge niciodată la scriptul meu.
drapel us
Trebuie să vă asigurați că nginx nu are directive de autentificare în configurația sa.
ajlittoz avatar
drapel in
Din cauza lipsei de detalii în documentație despre procesarea `WWW-Authenticate:` și interacțiunea dintre browser și server, mă gândesc să mă ocup eu de această fază de autentificare. În prezent, mă concentrez pe măsurile de securitate pentru a preveni atacurile de reluare și a crea jetoane de autentificare false. Principala mea preocupare este proiectarea unui schimb astfel încât pentru același utilizator/parolă, mesajul să nu fie niciodată același în încercările succesive.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.