Impostazione HTACCESS accesso file diretto da url

Ciao mi servirebbe un'informazione.
Premetto che non sono proprio esperto di diciture per htaccess, devo sempre cercare esempio dal web, il mio problema è il seguente, con la session posso bloccare ovviamente l'accesso a tutti i php del progetto e fin qui ci siamo, poi però ci sono altre cartelle come per esempio gli html che possono essere visti inserendo l'url del path, certo devono sapere il path però si vedono, questo però l'ho bloccato inserendo un htaccess nella cartella html e inserendo dentro l'htaccess deny form all, in questo modo l'html da url non si vede ma dentro il progetto generandolo dal php si vede perfettamente.
Lo stesso però devo fare per i JAVASCRIPT e se metto deny from all ehhh ovviamente i javascript non si vedono inserendo l'url però non riesco nemmeno ad usarli dentro il progetto...
Come faccio a bloccare l'accesso da url, cioè se uno scrive l'url/path del file javascript non si deve vedere il codice però devo poter usare il codice nel progetto.
Mi sono spiegato?Spero di si.
Chi mi aiuta?

Non sono sicuro di aver capito bene: vuoi che nessuno sia in grado di visualizzare il contenuto di un file JavaScript conoscendone l'URL, ma al contempo che chiunque possa utilizzare lo stesso codice JavaScript nel browser?
Se è così non credo che sia possibile: il client deve avere accesso al codice per interpretarlo. Al massimo puoi usare un code obfuscator per rendere il codice incomprensibile.

Se, invece vuoi rendere il codice JavaScript accessibile solo ad alcuni utenti, e vuoi controllarne l'accessibilità tramite PHP, puoi usare htaccess per vietare l'accesso dall'esterno e:

• includere il contenuto dei file JavaScript nelle pagine PHP che ti interessano, dopo aver controllato che l'utente abbia il diritto di accedervi, all'interno di un tag <script>
• creare un file PHP che ne "crei dinamicamente uno JavaScript", restituendo il contenuto di un file JavaScript dopo aver eseguito i controlli sul diritto di accesso ed aver impostato lo header content-type maniera opportuna (text/javascript se non erro).

Ehh si infatti, è lato client, ma possibile che non c'è un modo per impedire che il codice si veda inserendo direttamente l'url ma nello stesso tempo permettere l'esecuzione normale dal browser?Potrei impedire l'accesso a determinati IP ma non voglio farlo, non posso sapere quali ip permettere e quali no.
Per esempio io da PHP ho creato una funzione che mi permette di effettuare il codice solo se chiamato da Ajax in http request oppure in post oppure in get, io inserisco una securityAjaxCall all'inizio dello script PHP e se lo script viene invocato da un http request lo esegue ma se uno cerca di accedere dall'url quindi in GET non puo vederlo, certo vedrebbe solamente i print di default se ce ne sono, però comunque non accede, lo stesso se la chiamata viene fatta in post o in get uso la secutityPostCall o securityGetCall.
Si è linguaggio client però possibile che non si riesce a bloccarne la visualizzazione da accesso diretto da url?
Cioè siamo ancora indietro con la programmazione :)
O offusco il codice, però cavolo....

L'html riesco perchè lo creo direttamente dal PHP con una classe e quindi se inserisci l'url dell'html non si vede ti da errore 403 però lo crea tranquillamente dal PHP...Vorrei fare lo stesso per javascript.
Vedi non si vede:

http://fractalcosmo.altervista.org/M.../viewHome.html

Però si vede dall'interno del progetto....cioè dal PHP.

Citazione:

---

ma possibile che non c'è un modo per impedire che il codice si veda inserendo direttamente l'url ma nello stesso tempo permettere l'esecuzione normale dal browser?

---

Temo di no, ed il motivo è che il primo passo dell'esecuzione nel browser è proprio lo scaricamento del codice tramite una richiesta HTTP GET all'URL: il server non percepisce alcuna differenza tra una richiesta proveniente da un utente che inserisce manualmente un URL ed una richiesta effettuata automaticamente dal browser allo stesso URL.

Inoltre, anche qualora fosse possibile, sarebbe semplice creare un "finto browser" che, dopo aver ottenuto legittimamente un brano di codice JavaScript, lo mostra anziché eseguirlo. Il client ha bisogno di ottenere il codice sorgente per interpretarlo, ma una volta che l'ha ottenuto può farne ciò che desidera. È una situazione intrinseca nel linguaggi interpretati puri, non si tratta di essere "indietro con la programmazione" http://forum.it.altervista.org/image...icon_smile.gif.

Apro una partentesi: se ciò che ti preoccupa è che altri usino il tuo codice, credo tu possa semplicemente rilasciarlo sotto una qualche licenza (probabilmente proprietaria). Così facendo, usare il tuo codice senza il tuo permesso diventa una violazione della licenza...

Ma no figurati, io sono una pippa mica mi preoccupo che copiano il codice javascript, no no, solo per sicurezza, per non lasciare mostrate pagine di redirect.Alla fine mi sa che la cosa migliore è offuscarlo, io volevo trovare qualche altra soluzione.Alla fine non è un problema perchè tanto le pagine in php sono tutte protette anche se vede il redirect ma non può entrare dentro il php, però sa qual'è il path della pagina di home.Behh va beh.

Quindi dovresti fare una eccezione. Mettiamo che http://fractalcosmo.altervista.org/pagina.php (dove fai i controlli lato php.) Se si è su questa pagina e il client ha i giusti permessi può essere inoltrato nella pagina.html ed eventualmente può scaricare i file javascript (devi creare delle condizioni htaccess che indica la/e url html e i JavaScript abbinati al singolo url, altrimenti non si ha accesso hai javascript).Beh non so se esista qualcosa per .htaccess
EDIT:ho detto una bagianata, dal momento che è il client che deve scaricare il JavaScript e non il file html. I file JavaScript sono con estensione php? Se è si ri verifica le giuste condizioni che deve riportare (cioè quelle che fai per far vedere la pagina html).

Ehh calcola che io ho una cosa di questo genere e creo il template, dal template incluco i javascript con src

Codice PHP:

---


<?php
ob_start();
error_reporting(E_ALL ^ E_NOTICE);
include "template.php";

$username = rand();
$password = rand();
$dataora = date("dmYHis");

$html = new Tpl("html/login.html");
$html -> setTplVar(array(
"rand" => rand(),
"username" => $username,
"password" => $password,
"dataora" => $dataora
));
$html -> processTpl();
$html -> printTpl();
ob_flush();

?>

---

Io da qui creo la login.html e gli passo i parametri dataora, pinco pallo...poi nell'html c'è il javascript:

questa pagina qui viene creata così:

http://fractalcosmo.altervista.org/M...view/login.php

Adesso però il mio problema è che uno acceda ai file javascript scrivendo direttamente il link del path dall'url certo deve sapere la cartella e il nome file...Però potrebbe accedere.
Io ho quel parametro random che passo ad ogni file(per non stare a mettere sempre il cloud a modalità sviluppatore), forse potrei fare qualcosa con quel parametro rand, buhh, cioè se l'url javascript ha il parametro rand settato allora mostralo altrimenti non mostrarlo...Però dovrei riprendere in ogni file javascript tutto l'url e poi vedere se è settato con un if all'inizio e alla fine, cioè mi salvo il parametro rand in un hidden e lo metto globale con javascript poi in ogni file javascript metto una specie di isset se è isset rand allora carica altrimenti no....Buhh ho pensato ad una cosa di questo genere.Ma secondo me non serve a niente perchè quando poi uno va a scrivere il link vede lo stesso il codice perchè per il browser è un TEXT non un codice da eseguire dall'url.....Behh va behh, lascerò così.

Facciamo il punto della situazione.
1)Nella pagina login deve esser per forza presente il link al JavaScript e ovviamente si deve scaricare, altrimenti non può funzionare.
2)Dopo dovresti verificare nel database se sia presente quel hash (dal cookie) e in tal caso non mostrare la pagina di login (intesa come verifica di credenziali, perché potrebbe essere anche la stessa pagina con un contenuto diverso) e se i JavaScript che erano presenti prima non si debbono più utilizzare, si deve negare l'accesso .
3)Si una if che controlli (lato php) il valore auto-incrementato e il cookie, se risulta valido hai accesso nell'aria utenti con tutti i file di questo mondo, se risulta valido solo il valore auto-incrementato allora hai accesso hai file con quel estensione presente nel html e non ancora ad area utenti, se risulta falso ti viene restituita la pagina di login evitando il loop però eh.
Effettuare un controllo con un campo hidden (quindi dopo un'azione da parte dell'utente via html) e verificare tale valore non è efficace (tutto si può falsificare). Se crei qualcosa che si auto-incrementi (invece di un rand) lo salvi nel database in due parti (1:"generico" devi conservare l'ultimo creato. 2:"per utente se il login riesce devi salvare questo nelle info dell'utente, dovrebbe avere la validità di tempo indicato nella sessione e non quello nel cookie.)
Boh io lo vedrei con questo tipo di logica.

Eh si ma Darbula il problema non è caricare o no il javascript,cioè il javascript è nella cartella dei file javascript il problema è scrivere nell'url il path del javascript che si trova allinterno della cartella javascript, per indtenderci

fractalocosmo.com/miacartellajavascript/file.js

e lì che non si deve vedere il codice non nel login..Altrimenti non ho capito.

Non sono sicuro di capirti.
Forse dici che scriverai il file relativo nel html?Il browser lo trasforma in percorso assoluto comunque.
Però io intendo fractalocosmo.com/miacartellajavascript/file.php?auto=a0 Sto inserendo una query string dov'è all'interno di quel file dovrò verificare

Codice PHP:

---

if(isset($_GET['auto'])){
//Mettiamo che recupero l'auto-incremento dal database
if($row['auto-incremento'] == $_GET['auto']){
//okay
}else{
exit;
}
}


---

altrimenti sono io che non ho capito haha.

No no il php non è un problema, io vorrei bloccare l'accesso diretto ai file javascript dal path del progetto per capirci i file javascript sono in una cartella all'interno del progetto MvcWebLog se tu scrivi il path della cartella nell'url vedi tutto il codice javascript...Per gli html ci sono riuscito perchè gli HTML li creo dal php per esempio se tu vai qui:

http://fractalcosmo.altervista.org/M...tml/login.html

Ma quella è la pagina di login che si vede tranquillamente da

http://fractalcosmo.altervista.org/M...view/login.php

però dato che l'html lo creo dal PHP io ho messo un htaccess nella cartella html ed ho messo deny from all, lavora bene, cioè blocca l'url però chiamando l'html dal php si vede ed è quello che volevo, io vorrei fare la stessa cosa per i file javascript.
Se tu inserisci il path del file javascript non si deve vedere, ho provato ad iniettare il javascript dal php, come faccio per l'html e poi mettere l'htaccess deny from all nella cartella dei javascript ma non gli piace.
Buhh mi sa che non c'è soluzione, però vedo che ad esempio FB mette dei javascript tutti caricati con numeri random ad ogni login.Devo studiarci un pò su questa cosa.
Se tu apri FB e provi a vedere dal firebug gli script inclusi quelli sono dinamici, sembra che ad ogni caricamento cambia l'url e chiama un rsrc.php file che fa questo.

Premesso che non credo che l'accesso diretto tramite URL possa essere fonte di problemi di sicurezza, e ritengo quindi che quindi si possa soprassedere sull'argomento, un'idea consiste in:

1. impedire l'accesso alla cartella contenente i file JavaScript tramite htaccess
2. creare un'unica pagina php che funga da gateway per i file JavaScript
3. utilizzare l'URL del gateway anziché dei file JavaScript nelle pagine HTML/PHP che li richiedono

Questo permette di nascondere il percorso reale dei file JavaScript, non il loro contenuto (il quale non può comunque essere nascosto: se il browser deve interpretarlo, è necessario che possa accedervi).

Esempio
La cartella lib/javascript/ contiene i file JavaScript, il file index.html vuole includere lo script lib/javascript/a.js.
Sia la pagina gateway.php così strutturata:

Codice PHP:

---

header('Content-Type: application/javascript');
$script_path = identifier_to_path($_GET['script']);
$script = file_get_contents($script_path);
echo $script;


---

dove la funzione identifier_to_path accetta come input l'identificatore di uno script e ne restituisce il percorso. L'implementazione può avvenire attraverso lookup table (es. "lo script a si trova al percorso lib/javascript/a.js") o tramite altre strategie.
Per "identificatore" si intende una qualunque relazione in grado di identificare univocamente un file JavaScript (ad es. il nome del file senza estensione, un nome mnemonico assegnato allo script, il percorso relativo, ecc.); la scelta della strategia per l'assegnamento degli identificatori si ripercuote naturalmente sulla struttura della funzione identifier_to_path (nota: se si usano i percorsi relativi come identificatori, identifier_to_path altro non è che la funzione identità).

La pagina index.html diviene quindi:

Codice HTML:

---

<html>
    <head>
        <script src="gateway.php?script=a"></script>
    </head>
</html>

---

Funzionamento
Avendo utilizzato il file htaccess, l'accesso diretto tramite URL non è possibile.
Il file index.html contiene un'inclusione di gateway.php?script=a: il browser effettuerà una richiesta HTTP GET verso questo URL.
La richiesta giunge a gateway.php, assieme al valore a per il parametro di query script.
gateway.php calcola il percorso a cui corrisponde lo script etichettato come a, ne legge il contenuto e lo stampa.
Avendo impostato opportunamente l'intestazione, il documento viene interpretato come codice JavaScript.
Il browser riceve regolarmente il codice JavaScirpt (in chiaro).

Svantaggi
La politica di assegnamento degli identificatori è del tutto arbitraria e tende a mescolare un aspetto logico (funzionalità di uno script) con un dettaglio implementativo (posizione dello script sul file system), creando accoppiamento tra il codice e la posizione dei file.
L'efficienza e l'implementazione della funzione identifier_to_path dipendono/risentono della suddetta politica.
Il codice JavaScript è ancora visibile in chiaro, accedendo all'URL http://.../gateway.php?script=a (ma questo è intrinsecamente necessario).

Vantaggi
Impedisce l'accesso diretto tramite URL, rendendo comunque fruibile il codice JavaScript.
Si integra trasparentemente con altre tecniche (es. offuscamento).
Non richiede l'uso di basi di dati od altri strumenti inutilmente complessi.
Rende semplice restringere l'accesso ai file JavaScript, ad esempio ai soli utenti registrati (basta aggiungere un controllo su $_SESSION o simili).

Concludo tornando al punto di partenza: credo che nulla di tutto ciò sia significativo ai fini della sicurezza. Però è un esercizio divertente http://forum.it.altervista.org/image...e/icon_lol.gif.

Citazione:

---

Originalmente inviato da mzanella

Premesso che non credo che l'accesso diretto tramite URL possa essere fonte di problemi di sicurezza

---

Esatto: offuscare o cercare di rendere la cosa più complicata è pressoché inutile. Banalmente posso aprire gli strumenti per gli sviluppatori e intercettare la richiesta con la relativa risposta. Se poi è offuscato puoi renderne più complicata la lettura, ma il codice è quello.
Effettuare operazioni di questo tipo offre solamente una falsa idea di sicurezza e segretezza del proprio codice, che spesso è indice di veri e propri problemi di sicurezza nell'applicativo o nel codice stesso in questione.
Il codice JavaScript viene fornito al browser, punto. Puoi offuscarlo quanto vuoi, ma un potrà prendersi sempre la briga di leggerlo e capirne il funzionamento, e non c'è alcun mezzo che puoi usare per impedire ciò.
Quindi, non cercate di fare cose strane e scrivete codice giusto e sicuro in partenza.

Ma infatti il mio problema non era riferito alla sicurezza piu che altro ad ORDINE anche bloccare l html non è un problema di sicurezza ma di ordine..A parte che nel weblog non c è niente di sensibile e chiunque puo entrare basta che mi chiede un'utenza e comunque il weblog lo reputo abbastanza sicuro poi di sicuro c è solo la morte....anche perche se lo prende di mira anonimous lo buca ahahahah...No è questione di ordine cioè se la cartella weblog ha comunque un'area di accesso è giusto che solo gli utenti possano accedere ai file html o javascript....tutto qui, come programmatore queste cose le penso...cioe faccio un sito con un 'area di login e poi chiunque inserendo il path vede comunque il codice html non è da programmatori....certo deve conoscere il path ma rimane comunque un pugno in un occhio che un programmatore lascia l'accesso alle pagine html tramite inserimento del path del file dall'url a chiunque..tutto qui...notte

Citazione:

---

Originalmente inviato da fractalcosmo

No è questione di ordine cioè se la cartella weblog ha comunque un'area di accesso è giusto che solo gli utenti possano accedere ai file html o javascript....tutto qui, come programmatore queste cose le penso...cioe faccio un sito con un 'area di login e poi chiunque inserendo il path vede comunque il codice html non è da programmatori....certo deve conoscere il path ma rimane comunque un pugno in un occhio che un programmatore lascia l'accesso alle pagine html tramite inserimento del path del file dall'url a chiunque..tutto qui...notte

---

Ma se sono risorse statiche non dovrebbero contenere dati che richiedono l'autenticazione per essere ottenuti.
Al più potrebbe avere senso "proteggere" file da scaricare molto pesanti, per evitare che la banda venga consumata troppo facilmente.
In casi come questo potresti fare come ti ha indicato mzanella, al più aggiungendo una regola di mod_rewrite per usare un URL più tradizionale.

Ma se sono risorse statiche non dovrebbero contenere dati che richiedono l'autenticazione per essere ottenuti.

Ma a dire il vero non capisco il problema, per me se una cartella è comunque privata nel senso che c'è un'area di login, ogni file non dovrebbe essere accessibile da url path che sia un'immagine, un css un pinco pallo, non mi sembra di dire cose assurde, gli utenti registrati possono avere accesso ai file ma altrimenti se non sei loggato non deve solo essere il php non accessibile ma anche i singoli path della cartella...Molta gente cerca di nascondere anche i CSS.
Non è questione di sicurezza è questione di voler tenere la cartella solo per gli iscritti.
È come se ho un recinto in un giardino, ehh ma tanto il recinto che lo fai a fare uno lo scavalca e comunque nel giardino ci entra lo stesso l'importante è che non entra in casa....LOL.
Ciao

beh sono d'accordo. Invece di pensare se sia un file statistico, si dovrebbe pensare al suo utilizzo. Se il suo utilizzo è valido per un'area riservata, allora se non hai tali requisiti non hai diritto ad accedere a quei file. ps. beh fai un recinto alto 100 metri, così ti entrano con l'elicottero hahaha. No comunque è buona norma recintare la propria proprietà e nel caso ci sia una persona estranea puoi accusarlo di violazione di domicilio. Però attento non devi trattenerlo lì contro la sua volontà altrimenti ti accusa lui per sequestro di persona. hahaha