Sisupoika
25-07-2007, 01:43
Avete in azienda un web filtering che non vi consente di accedere alla vostra mailbox, o visitare forums, chats, ecc, e vi blocca anche se usate dei siti per proxy avoidance?
No problem se potete attivare IIS sulla vostra workstation :D
Se non vi sono restrizioni sul software (come dovrebbero esserci), ma soltanto un web filtering e avete la possibilita' di installare IIS o e' gia' installato, provate a creare nel sito hostato sulla vostra macchina una semplice pagina html e incollateci questa script di prova:
<html>
<head>
<script language="javascript">
var req;
function loadXMLDoc(url) {
req = false;
if(window.XMLHttpRequest && !(window.ActiveXObject)) {
try {
req = new XMLHttpRequest();
} catch(e) {
req = false;
}
} else if(window.ActiveXObject) {
try {
req = new ActiveXObject("Msxml2.XMLHTTP");
} catch(e) {
try {
req = new ActiveXObject("Microsoft.XMLHTTP");
} catch(e) {
req = false;
}
}
}
if(req) {
req.onreadystatechange = processReqChange;
req.open("GET", url, true);
req.send("");
}
}
function processReqChange() {
if (req.readyState == 4) {
if (req.status == 200) {
document.getElementById('AjaxWebRequest').innerHTML = req.responseText;
} else {
// something's gone wrong...
}
}
}
</script>
</head>
<body onload="loadXMLDoc('http://www.yahoo.com/')">
<div id="AjaxWebRequest"></div>
</body>
</html>
Provate dunque ad attivare un proxy con tanto di filtro per categorie sul vostro pc per fare un test e bloccate ad esempio www.yahoo.com (usato nell'esempio).
Provate dunque a visitare www.yahoo.com nel vostro browser: naturalmente il sito verra' bloccato dal proxy che avra' filtrato l'url negandolo.
Provate dunque ad avviare la pagina di prova appena creata, visitando col vostro browser http://localhost/paginatest.htm.
Naturalmente, poiche' c'e' un proxy che filtra gli url non consentiti, la richiesta Ajax dovrebbe visualizzare la pagina che avverte tipo "Yahoo.com - category x blocked" cosi' come avverrebbe nel browser; invece, cosa accade?
Vedrete comparire la home page di Yahoo. :D
Spiegazione: l'XmlHTTP bypassa le impostazioni del proxy/filtro locale (non mi e' ancora noto se funziona con configurazioni proxy/filtering piu' avanzate), caricando la pagina richiesta direttamente.
Il layout della pagina sara' sballato a video perche' i riferimenti delle immagini, css, ecc. saranno relativi al vostro http://localhost, ma questo e' solo un esempio. Una soluzione vera e propria vorrebbe una riscrittura di links, image/sources, ecc. ecc. per poter usare alcuni siti con questo sistema. E ci sarebbero naturalmente problemi con la questione cookies, sessione, ecc.
E' solo uno spunto: sottolinea che e' possibile con questo x di sicurezza (bug? non lo so ancora) accedere a risorse web che si suppongono bloccate in un certo modo. Esso visualizza soltanto l'html della pagina richiesta; per poter interagire con le pagine ce n'e' di strada da fare e naturalmente mi fermo senza procedere in dettaglio qui per ovvie ragioni.
Si tratta a mio avviso di un problema di sicurezza, che seppure restringibile ad uno specifico tipo di situazione (scenario piu' semplice: proxy filtering attivato localmente sul browser e non disattivabile a causa di una protezione password dell'admin, ma l'utente della workstation puo' fare tutto il resto sulla sua macchina, come es. installare/usare IIS - sono innumerevoli i cosiddetti "amministratori" che attivano semplici filtri ma lasciano pieni poteri all'utente) non mi sembra documentato - con mia sorpresa, a seguito di ricerche effettuate googlando.
Provate ad immaginare uno scenario tipo:
l'amministratore ha
- ristretto l'uso del browser per i pochi siti necessari al lavoro del dipendente, in modo da evitare che egli si "distragga" dal suo lavoro;
- ristretto l'accesso alle cartelle di sistema
- eliminato "Run" (Esegui) dal menu Start
- disattivato il tasto Windows in modo che non possiate avviare TastoWindows+R ( = Run )
- disattivato il pannello di controllo
- disattivata la possibilita' di avviare processi da Task Manager
- disattivato prompt dei comandi dal collegamento nel menu Start
ecc ecc
Virtualmente l'utente sarebbe impossibilitato ad eseguire Security Policies o Group Policies per esempio, rimanendo bloccato.
MA supponiamo che (95% dei casi, occhio e croce? :D) abbia lasciato l'utente comme Administrator della sua macchina, come e' di default (si faccia riferimento ancora una volta all'altro thread :asd: ), magari solo perche' Norton Antivirus funziona solo con Administrator ( :asd: ), allora l'utente potrebbe prepararsi una paginetta html su uno spazio web qualunque, che contiene l'XML ti un tipico file di Management Console (MMC), magari - LOL giusto per esempio - Group Policies (Gpedit.msc).
Boom: l'utente essendo Administrator potrebbe installare IIS, copiare lo script di cui sopra, modificarlo affinche' visualizzi nel browser - bypassando il filtro - l'XML di gpedit.
Potrebbe copiare l'XML in un file sul desktop, chiamarlo gpedit.msc e toh... sorpresa :D
Full power.
Ma questo, ovviamente, e' solo un esempio. :D
Mi sono accorto di questa cosa quasi per caso, controllando tutt'altra storia.
Buona notte :)
:fagiano:
No problem se potete attivare IIS sulla vostra workstation :D
Se non vi sono restrizioni sul software (come dovrebbero esserci), ma soltanto un web filtering e avete la possibilita' di installare IIS o e' gia' installato, provate a creare nel sito hostato sulla vostra macchina una semplice pagina html e incollateci questa script di prova:
<html>
<head>
<script language="javascript">
var req;
function loadXMLDoc(url) {
req = false;
if(window.XMLHttpRequest && !(window.ActiveXObject)) {
try {
req = new XMLHttpRequest();
} catch(e) {
req = false;
}
} else if(window.ActiveXObject) {
try {
req = new ActiveXObject("Msxml2.XMLHTTP");
} catch(e) {
try {
req = new ActiveXObject("Microsoft.XMLHTTP");
} catch(e) {
req = false;
}
}
}
if(req) {
req.onreadystatechange = processReqChange;
req.open("GET", url, true);
req.send("");
}
}
function processReqChange() {
if (req.readyState == 4) {
if (req.status == 200) {
document.getElementById('AjaxWebRequest').innerHTML = req.responseText;
} else {
// something's gone wrong...
}
}
}
</script>
</head>
<body onload="loadXMLDoc('http://www.yahoo.com/')">
<div id="AjaxWebRequest"></div>
</body>
</html>
Provate dunque ad attivare un proxy con tanto di filtro per categorie sul vostro pc per fare un test e bloccate ad esempio www.yahoo.com (usato nell'esempio).
Provate dunque a visitare www.yahoo.com nel vostro browser: naturalmente il sito verra' bloccato dal proxy che avra' filtrato l'url negandolo.
Provate dunque ad avviare la pagina di prova appena creata, visitando col vostro browser http://localhost/paginatest.htm.
Naturalmente, poiche' c'e' un proxy che filtra gli url non consentiti, la richiesta Ajax dovrebbe visualizzare la pagina che avverte tipo "Yahoo.com - category x blocked" cosi' come avverrebbe nel browser; invece, cosa accade?
Vedrete comparire la home page di Yahoo. :D
Spiegazione: l'XmlHTTP bypassa le impostazioni del proxy/filtro locale (non mi e' ancora noto se funziona con configurazioni proxy/filtering piu' avanzate), caricando la pagina richiesta direttamente.
Il layout della pagina sara' sballato a video perche' i riferimenti delle immagini, css, ecc. saranno relativi al vostro http://localhost, ma questo e' solo un esempio. Una soluzione vera e propria vorrebbe una riscrittura di links, image/sources, ecc. ecc. per poter usare alcuni siti con questo sistema. E ci sarebbero naturalmente problemi con la questione cookies, sessione, ecc.
E' solo uno spunto: sottolinea che e' possibile con questo x di sicurezza (bug? non lo so ancora) accedere a risorse web che si suppongono bloccate in un certo modo. Esso visualizza soltanto l'html della pagina richiesta; per poter interagire con le pagine ce n'e' di strada da fare e naturalmente mi fermo senza procedere in dettaglio qui per ovvie ragioni.
Si tratta a mio avviso di un problema di sicurezza, che seppure restringibile ad uno specifico tipo di situazione (scenario piu' semplice: proxy filtering attivato localmente sul browser e non disattivabile a causa di una protezione password dell'admin, ma l'utente della workstation puo' fare tutto il resto sulla sua macchina, come es. installare/usare IIS - sono innumerevoli i cosiddetti "amministratori" che attivano semplici filtri ma lasciano pieni poteri all'utente) non mi sembra documentato - con mia sorpresa, a seguito di ricerche effettuate googlando.
Provate ad immaginare uno scenario tipo:
l'amministratore ha
- ristretto l'uso del browser per i pochi siti necessari al lavoro del dipendente, in modo da evitare che egli si "distragga" dal suo lavoro;
- ristretto l'accesso alle cartelle di sistema
- eliminato "Run" (Esegui) dal menu Start
- disattivato il tasto Windows in modo che non possiate avviare TastoWindows+R ( = Run )
- disattivato il pannello di controllo
- disattivata la possibilita' di avviare processi da Task Manager
- disattivato prompt dei comandi dal collegamento nel menu Start
ecc ecc
Virtualmente l'utente sarebbe impossibilitato ad eseguire Security Policies o Group Policies per esempio, rimanendo bloccato.
MA supponiamo che (95% dei casi, occhio e croce? :D) abbia lasciato l'utente comme Administrator della sua macchina, come e' di default (si faccia riferimento ancora una volta all'altro thread :asd: ), magari solo perche' Norton Antivirus funziona solo con Administrator ( :asd: ), allora l'utente potrebbe prepararsi una paginetta html su uno spazio web qualunque, che contiene l'XML ti un tipico file di Management Console (MMC), magari - LOL giusto per esempio - Group Policies (Gpedit.msc).
Boom: l'utente essendo Administrator potrebbe installare IIS, copiare lo script di cui sopra, modificarlo affinche' visualizzi nel browser - bypassando il filtro - l'XML di gpedit.
Potrebbe copiare l'XML in un file sul desktop, chiamarlo gpedit.msc e toh... sorpresa :D
Full power.
Ma questo, ovviamente, e' solo un esempio. :D
Mi sono accorto di questa cosa quasi per caso, controllando tutt'altra storia.
Buona notte :)
:fagiano: