Protezione Pagine senza PHP 
Autor: Orlando B.
Visitado 2376,
Followers 1,
Compartido 0
Buongiorno. Sto cercando di proteggere con password alcune pagine del mio sito usando l'opzione prevista in "Website X5 Evolution 9". Il problema è che nel server che ospita il mio sito non è possibile attivare il linguaggio php che credo sia indispensabile per la sopra menzionata opzione. E' possibile proteggere con password le pagine a mio piacere bypassando il requisito del php? Magari con qualche script html da inserire "ad hoc"? Grazie mille in anticipo. Orlando Bartolomei
Publicado en
... con il programma, certamente no, ...e che mi venga in mente, ...con SwishMax.4-IT sarebbe possibile senza supporto PHP, ...ma occorre avere il programma e saperlo programmare...
... magari se cerchi in RETE potresi trovare soluzioni JavaScript...
.
bye, KolAsim
Buongiorno Orlando,
attualmente esistono molti server che supportano il PHP anche gratuiti, il mio consiglio è quello di provare a cambiare server, utilizzandone uno con il supporto PHP.
Un nostro partners è One.com e se hai comprato Website X5 Evolution 9 hai un anno gratuito su questo hosting provider.
se non hai PHP puoi provare ad utilizzare il file htaccess per proteggere delle cartelle o dei singoli file
[codice]
AuthUserFile /full/path/to/.htpasswd
AuthType Basic AuthName "My Secret Page"
<Files "mypage.html">
Require valid-user
</Files>
[/codice]
... mmmhhhmm... ...ci vorrà un pellerossa, altrimenti non va; ...digilander e tin non funge...
... tanto per allargare le idee, la base da cui partire per gestire un controllo tramite SwishMax parte da questi miei sempre esclusivi esempi, ...ai quali andrebbe applicata una condizione per accedere alla pagina leggi in base alla pass inserita...
... file che scrive: http://www.zspace.it/kolasim/miei_files/sharedobject/scrive_K.html
... file che legge: http://www.zspace.it/kolasim/miei_files/sharedobject/legge_K.html
...
... comunque sono convinto che con J.S. e cockie si potrebbe ottenere qualcosa di simile ai miei esempi...
.
bye,KolAsim
No. Non ha senso spostare la verifica nome/password sul lato client ... chiunque potrebbe visualizzare il codice per "scovare" i dati reali .... a meno che non si usino tecniche per offuscare/crittografare il codice, ma .... obbiettivamente, mi sembra una cavolata. Andrei cauto anche con swishmax, l'swf viene scaricato sul client ed è sempre "decompilabile".
Autor
Grazie mille per il suggerimento.In ogni caso avrei bisogno di ulteriori informazioni.
Dove trovo il file htaccess? Dove dovrei inserirlo?
Dove devo inserire esattamente il suddetto codice nel programma "Website X5"?
Saluti cordiali.
Orlando
fai cosi'
in impostazioni generali togli il segno di spunta alla attiva protezione codice html (se è attivo)
in alto a dx clicca su esperto e in coda al codice personalizzato per la sessione head incolla questo codice <body oncontextmenu="return false" ondragstart="return false" onselectstart="return false">
spero di esserti stato utile se è tutto ok mandami una mail a ***
... e la password dov'è...?...
... l'unico metodo realizzabile da subito, per quel che mi riguarda, su qualsiasi server, è sempre quello suggerito da me...
.
Nel tuo caso, i dati per la validazione dove vengono memorizzati? Non ho capito gli esempi che hai postato, forse non hanno funzionato con una variabile impostata, salvata e non letta. Forse perchè non è stata salvata sul lato server e quindi avendo fatto salvataggio e lettura con sessioni diverse (browser diversi) non si poteva leggerne il contenuto. Spiegaci meglio come hai realizzato gli esempi postati.
http://www.unofficialwsx5.com
... deriva da questo che avevo detto come alternativa senza SM:
.
La verifica di nome e password presuppone che si possano confrontare i dati immessi nel browser con quelli memorizzati da qualche parte.
La verifica può essere fatta in chiaro, come fa icm, e quindi da qualche parte vengono memorizzati i dati "in chiaro" e confrontati con quelli immessi. Chiunque abbia accesso alla struttura che contiene i dati in chiaro riesce a conoscerli, in un modo o nell'altro. Ma soprattutto, la verifica presuppone che i dati immessi siano confrontati con l'intero database delle credenziali, quindi anche quelle degli altri utenti.
La verifica viene fatta con un qualsiasi algoritmo di HASH che ne codifica i valori chiaro per fornirne una stringa pseudo-crittografata. Quindi nella solita struttura dei dati vengono memorizzati i dati crittografati e l'atto della verifica presuppone che i dati immessi vengano a loro volta crittografati e confrontati con quelli nel database. Questo è il sistema solitamente usato. Tuttavia è da considerare che ad una stessa codifica possono corrispondere più valori "in chiaro", ovvero due password possono fornire la stessa stringa codificata. E' un fatto del tutto normale, ma che comporta una riduzione dello spazio delle soluzioni se si decide di eseguire un attacco di tipo brute-force per ritrovare i dati. E' un sistema comunemente utilizzato da tantissime applicazioni e ne soffrono persino i prodotti office di microsoft. E' assolutamente fisiologico.
Da queste due premesse vien fuori un solo teorema e cioè che se si ha in mano la struttura dei dati, in un modo o nell'altro ed in un tempo più o meno lungo, si ricavano i dati degli utenti, tutti gli utenti.
Se la verifica delle credenziali viene svolta dal meccanismo cookie/js ... tutto il codice, struttura dei dati compresa, è perfettamente leggibile ... http://www.serzio.it/evo9/cms/res/x5engine.js ... per i cookies è la stessa cosa.
Se si effettua tramite file di flash (swishmax) il discorso è simile:
... tratto dall'swf da te pubblicato nell'esempio di qualche post più sopra che ho "decompilato" con un prodotto facilmente reperibile in rete ... ce ne sono decine.
I dati si ricavano dalla decodifica del file swf e quindi siamo punto al punto di partenza.
Il trucco è di evitare che i dati, e quindi la validazione delle credenziali, siano spostati sul lato client, ovvero quello che ti ostini a sostenere.
E quindi la validazione DEVE rimanere in un posto non accessibile al client. Il webserver, un server esterno diverso .... qualsiasi cosa che abbia la capacità di non mostrare la struttura dei dati al client.
L'unico sistema più comodo nel nostro caso è quello che fa uso del php.
Anche in questo caso, spero che la chiacchierata sia stata utile per capire qualcosa di più di cosa si cela "dietro le quinte".
http://www.unofficialwsx5.com
... la chiacchierata è stata utile, ...e non c'era bisogno di decompilare!!!, ...il mio è l'unico esempio esistente con sorgente libero ed inventato da me, adatto ad infiniti scopi, per esempio usato anche nell'altra mia invenzione unica, sul controllo del suono attivo in tutte le pagine del sito, alternativa provvisoria, perché senza PC e programmi non riesco a sviluppare quella che avevo già progettato senza cockie o come si chiamano, ma dentro un canale virtuale attivo solo tramite il motore del flashplayer di sistema, ...ma non utilizzabile nel caso specifico...
... se provi, ci trovi ancora lo SWI, lì da diversi anni... (in uno spazio web precario che non è il mio ed in cui sono ospite non so fin quando)
... comunque, tutto è relativo a ciò che si vuole veramente ottenere , e la mia è solo una idea reale, come dimostrato, ...legata alla domanda iniziale, ...e certo , col PHP sarebbe tutto un altro discorso, ...ma di metodi alternativi non si è fatto avanti nessuno con qualche proposta/idea diversa, magari su ambienti che non conosco...
... non devo e non voglio convincere nessuno, chi ha da intendere intenda...
...
Siamo tutti d'accordo nel dire che website ha avuto l'indiscusso merito di trasformare chiunque in uebmaster (con la scherzosa "u" piuttosto che "w"), anche quelli senza alcuna conoscenza di html, php, css etc etc ... ma dobbiamo prendere atto che molti si cimentano in realizzazioni che richiederebbero ben altre competenze.
Quello delle aree riservate è un tema estremamente delicato, non stiamo parlando di una galleria fotografica che al massimo si vede male o non funziona, ed il fatto che viene trattato incoscientemente con una superficialità eccessiva mi spinge a mettere i puntini sulle "i".
Basti pensare ad un semplice sito web di uno studio medico che decida di rendere disponibili informazioni per i propri assistiti. Oppure un laboratorio di analisi che decida di consegnare i referti tramite web. Oppure un negozio, o uno studio legale, una scuola .... posso farti molti esempi in cui una incosciente imperizia possa consentire la divulgazione di informazioni riservate causando danni immensi ai clienti ed ai responsabili della privacy. Tutte situazioni possibili, nella stessa galleria dell'answers ho visto diversi siti web di questo tipo e purtroppo in tempi di crisi economica non sono pochi quelli che decidono per il "faidate" piuttosto che affidarsi a professionisti veri.
Una volta chiarita l'importanza di questo argomento, passo a chiarire la mia testardaggine nel non farti passare l'informazione sbagliata che una area riservata possa essere realizzata senza uno strumento minimo che può essere un php o un asp.
Mi piacerebbe che fosse ben chiaro che il sistema da te proposto non consente una protezione accettabile dei contenuti di una pagina. Con js/cookie ... non ci perdere nemmeno un secondo in più di tempo .... non è possibile ottenere qualcosa di accettabile. Non sono accettabili tutte le situazioni in cui si ha la gestione della validazione sul lato client. Con swf, stessa cosa, il file viene eseguito sul client e quindi proprio questa cosa lo rende insicuro.
Poi ... ciascuno faccia le sue consapevoli scelte, ma e' eticamente corretto specificare che esiste un rischio per la riservatezza.
PS. Così come ho decompilato il tuo file, nella stessa maniera si può decompilare qualsiasi swf, come ho fatto molte altre volte per capire il funzionamento di qualche effetto interessante trovato in rete.
http://www.unofficialwsx5.com
Un esempio di leggerezza inconsapevole potrebbe essere anche l'utilizzo di script fatti male:
che invece non protegge proprio nulla:
Occhio gente!!! In rete c'e' tanta gente cattiva.
http://www.unofficialwsx5.com
... siamo sempre là, ...per quello che potrei fare io, ...saprei come regolarmi, PHP o non PHP, più no che sì, perchè non avrei niente da nascondere al cretino di turno che crede di essere intelligente bucando qua e là; ...invece, per un altro che avrebbe dati sensibili di una certa importanza da salvaguardare, farebbe bene sì a guardarsi intorno, e per questo hai fatto bene ad evidenziarlo; ...ma è ovvio che il PHP/o ASP che sia è un altro pianeta, ...ma è anche altro che fa la differenza...
Non ti fermare alle apparenze. Il più delle volte ci sono reali motivi a spingere i "cretini" a fare quello che fanno. Te ne indico qualcuno:
Per questo è necessario fare ugualmente attenzione.
http://www.unofficialwsx5.com