I proxy Web possono distinguere tra i file JScript e Javascript?

1

È una best practice relativamente comune per filtrare file eseguibili e script da un utente standard a livello proxy / gateway nell'ambiente aziendale. Mentre i file EXE / BAT / CMD sono abbastanza facili, e discutibilmente .VBS (anche se suppongo che in teoria possa essere utilizzato in un sito Web che è solo compatibile con IE), è semplice implementare soluzioni per Microsoft JScript (.JS)?

Sembra complicato in quanto l'estensione del file è la stessa e la lingua è quasi identica.

In alternativa, sono necessarie ispezioni dell'intestazione del tipo di contenuto per verificare se vengono scaricate, piuttosto che eseguite nel contesto del browser Web relativamente sicuro / necessario?

Oppure la riconfigurazione del SO impedisce l'esecuzione di file .js da wscript più comune per mitigare questo? O ispezione del contenuto per rilevare l'uso di metodi pericolosi (l'istanza di oggetti WScript viene in mente).

Per quello che vale, mi occupo di download accidentale ed esecuzione di script dannosi (ma non segnalati da AV) dagli utenti qui.

    
posta user2867314 03.03.2017 - 13:28
fonte

1 risposta

1

Secondo Wikipedia ( link ):

[Microsoft] did not want to deal with Sun Microsystems about the trademark issue, and so they called their implementation JScript. A lot of people think that JScript and JavaScript are different but similar languages. That's not the case. They are just different names for the same language, and the reason the names are different was to get around trademark issues

Quindi per rispondere alla domanda nel titolo, sono la stessa cosa.

Modifica: per commento qui sotto da @dandavis, Jscript è in realtà peggio.

Non so nulla di Windows / IE, ma credo che puoi configurare IE per non eseguire JS (o solo per determinati siti) - il che dovrebbe significare che potresti potenzialmente consentire a JS di eseguire solo per siti attendibili, il che dovrebbe limitare la superficie di attacco.

Se un po 'di Javascript veniva scaricato da qualcosa di diverso da un browser, è possibile controllare quale sia lo User-Agent per la richiesta (anche se dovresti aspettarti che venga falsificato).

Penso che (ma ancora una volta, non proprio la mia area) cose come EMET potrebbero essere di aiuto, come sarebbe qualcosa come la whitelisting delle applicazioni (penso che la funzionalità sia parte di AppLocker, ma non so fino a che punto può Aiuto).

Realisticamente, non penso che saresti in grado di bloccare a livello globale Javascript, perché spezzerebbe un discreto numero di siti che le persone potrebbero voler utilizzare.

Modificato per tenere conto di ulteriori informazioni nel commento qui sotto:

OK - per quel caso (grazie per aver specificato), penso che ci siano due modi:

  • per link , sembra possibile disabilitare le estensioni della shell, che credo faccia ciò che si desidera.

  • Mi aspetterei (ma non lo so) che EMET o AppLocker avrebbero qualcosa nelle loro opzioni per bloccare le chiamate Wshell (penso che controllerei prima EMET)

Se disponi di un proxy che potrebbe eseguire l'introspezione dei contenuti (e non avere a che fare con i dati protetti da TLS), potresti essere in grado di bloccare specifici script che contengono chiamate a wshell, ma come dici tu, quasi certamente andrà essere un lungo gioco di whack-a-mole che funziona sempre e solo per lo più.

Modifica: mi è venuto in mente un altro pensiero, che consisteva nel tentare di costringere gli utenti a selezionare la directory di download per i download tutti - presumo che la maggior parte si interromperà quando vedrà un download .JS. Sfortunatamente, per link , questo non è più possibile per IE. Sembra essere per es. Chromium ( link ), ma probabilmente non aiuta. È anche una protezione abbastanza debole - e potrebbe quindi essere un po 'un vicolo cieco.

    
risposta data 03.03.2017 - 14:02
fonte

Leggi altre domande sui tag