Netscape Plugin Application Programming Interface ( NPAPI ) este o arhitectură de dezvoltare a plug -in-uri multiplatformă susținută de multe browsere .
Interfața a fost proiectată pentru familia de browsere Netscape Navigator începând cu Netscape Navigator 2.0 și a fost implementată de multe alte browsere de atunci. Cu toate acestea, Internet Explorer nu acceptă această interfață începând cu versiunea 5.5 [1] [2] [3] .
Prevalența interfeței poate fi legată de simplitatea acesteia. Pluginul declară că funcționează cu anumite tipuri de date (de exemplu, „audio/mp3”) folosind informațiile din fișier. Când browserul întâlnește acest tip de date, încarcă plug-in-ul asociat cu acesta, alocă spațiu pe pagina redată și îi trimite un flux de date . Pluginul este pe deplin responsabil pentru datele afișate, inclusiv video, audio și altele. Prin urmare, pluginul funcționează în interiorul paginii, spre deosebire de browserele mai vechi care trebuiau să lanseze o aplicație externă pentru a afișa un tip de date necunoscut.
Interfața API necesită ca fiecare browser să implementeze un număr mic de funcții. Sunt necesare aproximativ 15 funcții pentru a inițializa, crea, distruge și localiza pluginul. NPAPI acceptă scripting, imprimare, pluginuri pe ecran complet, pluginuri fără ferestre și fluxuri de date.
Ideea de plug-in-uri nu a apărut cu Netscape Communications în sine , ci cu Adobe Systems . John Warnock , CEO , și Alan Paget , unul dintre principalii dezvoltatori ai Acrobat Reader , sperau că tânărul format PDF poate fi folosit dincolo de desktop . Astfel, Netscape a lansat în curând prima versiune a Navigator. Paget și colegul dezvoltator Eshwar Priyadarshan încercau să găsească o modalitate de a transforma PDF-ul într-o parte integrantă a World Wide Web . Rezultatul a fost un demo live prezentat lui Warnock și James Clark , directorii executivi ai Netscape. Înainte de această demonstrație, formatul nativ pentru World Wide Web era doar HTML și imaginile încorporate în paginile web care îl utilizau. Legăturile către orice alt tip de fișier ar determina descărcarea și deschiderea fișierului respectiv în aplicația corespunzătoare . Această demonstrație a arătat cum, făcând clic pe un link către un fișier PDF, a deschis o fereastră de browser care a combinat perfect afișarea PDF și HTML. Clarke a întrebat cine a implementat suportul în cadrul Netscape și a fost surprins să afle că integrarea s-a făcut fără implicarea Netscape, cu doar puțină inginerie inversă a browserului Netscape.
Săptămâna următoare, companiile au adus pe piață tehnologia sub numele de Allan's Hack. În timp ce Netscape se pregătea pentru integrarea strânsă cu PDF pe care Adobe ar fi așteptat-o cu nerăbdare, Paget a venit cu o abordare diferită, arhitectura plug-in. Dezvoltatorii Adobe Gordon Dow și Nabeel Al-Shamma au adăugat recent o arhitectură plugin la Acrobat Reader folosind experiența de dezvoltare în afara echipei Acrobat Reader. Paget a fost unul dintre dezvoltatorii externi și spera că, dacă li s-ar putea alege altor companii, acestea vor alege să extindă web-ul, așa cum făcuse echipa Adobe. Clarke și echipa au fost convinși de acest lucru, așa că și-au propus să proiecteze un API care să susțină noua arhitectură.
Caracteristica de suport pentru limbajul de scripting vă permite să utilizați cod JavaScript pe o pagină web pentru a interacționa cu pluginul. Diverse versiuni de Netscape și Mozilla au acceptat această funcționalitate folosind diferite tehnologii: LiveConnect , XPConnect și npruntime .
Următoarele browsere acceptă pluginuri NPAPI:
Pentru o vreme, Internet Explorer a furnizat pluginuri create pentru Netscape. Acest lucru s-a datorat numărului mic de funcții ActiveX implementate folosind fișierul „plugin.ocx”, care a acționat ca un strat între pluginurile ActiveX și NPAPI. IE va încărca ActiveX și va folosi pluginurile definite pentru pagină. Microsoft a făcut o declarație că utilizarea NPAPI este nesigură (sau API-ul implementat în IE este nesigur) și a întrerupt suportul începând cu versiunea 5.5SP2 [1] [2] [3] .
O concepție greșită populară despre tehnologia NPAPI este că este mai sigură decât ActiveX. Cu toate acestea, ambele tehnologii rulează cod nativ și au privilegiile procesului părinte. Dacă procesele părinte au aceleași privilegii, atunci un plugin NPAPI rău intenționat și ActiveX pot provoca daune similare. Este demn de remarcat faptul că pluginurile NPAPI pot fi făcute mai sigure prin simpla schimbare a contului de utilizator . În general, este posibil să instalați și să rulați pluginuri cu drepturi de utilizator, în timp ce utilizarea ActiveX necesită privilegii administrative. Cu drepturi limitate, pluginul nu va putea face prea mult rău .
O altă diferență importantă între NPAPI și ActiveX este că NPAPI-urile sunt folosite doar ca pluginuri de Internet, în timp ce ActiveX este folosit pentru o gamă largă de sarcini, inclusiv utilizarea în aplicațiile Windows . Utilizatorul mediu de Windows are o gamă uriașă de controale ActiveX instalate, dintre care unele sunt etichetate „sigure pentru scripting”, dar de fapt nu sunt sigure. Oricare dintre ele poate fi folosit pentru a ataca computerul utilizatorului [5] .
O altă diferență pentru NPAPI este că implementările sale (înainte de Mozilla Firefox, vezi mai jos) nu au descărcat sau instalat automat pluginurile lipsă. A fost afișat un stub în locul unui astfel de plugin. Dacă utilizatorul făcea clic pe el, atunci era redirecționat către site-ul web Netscape, unde putea găsi, descărca și instala pluginul corespunzător. Desigur, o astfel de schemă este incomodă pentru utilizator, dar elimină unul dintre vectorii de atac folosiți de malware .
Internet Explorer citește din HTML informații despre locația ActiveX instalată. Dacă controlul ActiveX nu este instalat, IE va descărca automat elementul lipsă din sursa specificată, apoi vă va cere să acceptați semnătura digitală și să faceți clic pe butonul de instalare. Această schemă funcționează într-o infrastructură de încredere, dar utilizarea metodelor de inginerie socială poate convinge utilizatorul să ignore avertismentele și să conducă la consecințe negative. Un număr mare de site-uri spyware, adware și rău intenționate folosesc acest vector de atac . Pentru a reduce riscurile, Microsoft a trebuit să ridice nivelul de securitate implicit pentru controalele ActiveX și să mențină o listă de controale ActiveX rău intenționate.
Mozilla Firefox încearcă să ofere o cale de mijloc. Dacă pluginul este necunoscut, utilizatorul va fi notificat și direcționat către mozilla.org cu o conexiune securizată . Utilizatorul poate permite Firefox să descarce și să instaleze pluginul corespunzător. Acest model nu spune browserului unde ar trebui să fie încărcat pluginul: pluginurile sunt încărcate dintr-o locație centrală. Acest lucru permite Firefox să ofere un mecanism de instalare perfect pentru pluginuri de încredere și de încredere. Acest model are implicit încredere în serviciul de căutare pentru pluginuri „bune”, ceea ce necesită o securitate sporită a acestui site.