Pagine HTML criptate
Gigino
possibile poi decriptarle?
Ad esempio per modifiche in caso perdo la pagina originale?
Andrea D'Amore
"Gigino" <gi...@dagigi.info> wrote:
> Ma le pagine criptate con programmi tipo HTML uard o HTML Guardian è
> possibile poi decriptarle?
Ovviamente sì altrimenti il browser stesso non potrebbe renderle a
schermo. Non è una criptatura di una pagina HTML, è un artifizio tramite
javascript, giusto per cronaca inoltre:
Errors found while checking this document as XHTML 1.0 Transitional!
Result: 202 Errors, 78 warning(s)
Address: http://www.htmlguard.com/sample.html
Euclide
> In article <4b359876$0$9753$6e1e...@read.cnntp.org>,
> "Gigino" <gi...@dagigi.info> wrote:
>
>> Ma le pagine criptate con programmi tipo HTML uard o HTML Guardian è
>> possibile poi decriptarle?
>
> Ovviamente sì altrimenti il browser stesso non potrebbe renderle a
> schermo. Non è una criptatura di una pagina HTML, è un artifizio tramite
> javascript, giusto per cronaca inoltre:
>
Veramente per il php ci sarebbero ioncube e zendencoder che servono a
proteggere lo script dalla copia?
Cmq, unica cosa, ho criptato una pagina html in quanto via form mi deve
inviare anche la pwd come campo hidden e quidni vorrei sapere quanto è
sicuro HTML Guard, anche se in definitiva il sapere la password non fa
altro che permettergli di spendere dei soldi effettuando l'ordine.
Se non cripto affatto si vede tutto in chiaro.
Leonardo Serni
wrote:
>>> Ma le pagine criptate con programmi tipo HTML uard o HTML Guardian �
>>> possibile poi decriptarle?
>> Ovviamente s� altrimenti il browser stesso non potrebbe renderle a
>> schermo. Non � una criptatura di una pagina HTML, � un artifizio tramite
>> javascript, giusto per cronaca inoltre:
>Quindi � pi� un encoding come quello per il php che una criptazione?
Dipende cosa intendi per "encoding" e cosa per "criptazione".
Se sostituisci una pagina HTML con
<script...>
var htmlEncryptedBody='....';
document.write(decrypt(htmlEncryptedBody));
</script>
quella e' una criptazione. Che poi uno la sfondi in 8 secondi netti non
cambia la cosa.
>Cmq, unica cosa, ho criptato una pagina html in quanto via form mi deve
>inviare anche la pwd come campo hidden e quidni vorrei sapere quanto �
>sicuro HTML Guard
Guarda: se ti poni una domanda cosi', ho idea che tu debba ripensare l'
intera architettura.
Cominciamo da principio: cos'e' che vorresti fare?
Leonardo
--
The cock doth craw, the day doth daw,
the channerin' worm doth chide:
gin we be mist oot o' oor place,
a sair pain we maun bide.
Euclide
>
> <script...>
> var htmlEncryptedBody='....';
> document.write(decrypt(htmlEncryptedBody));
> </script>
>
>
> Guarda: se ti poni una domanda cosi', ho idea che tu debba ripensare l'
> intera architettura.
>
Che architettura in un sito di 5 pagine?
Ho solo creato un form che invia via sms i suoi dati e siccome devo
decidere se lasciare utente e pwd di accesso all'invio nella pagina del
form (pagina in html) o invece nel programmino di invio in PHP (solo che
poi basta che uno vede la sitassi della riga di invio ed invia lo
stesso? e quindi in una pagina "criptata" potrebbero restare pi� al
sicuro di invece una pagina non criptata, forse sarebbe emglio metterli
in un file criptato e fuori dall'albero directory ma per ora i dati non
vengono presi da un file o db e poi casomai anche in quel caso non �
proprio sicuro lo stesso che uno non usi il servizio erroneamente.
> Cominciamo da principio: cos'e' che vorresti fare?
>
BHO! :P
Si fa quel che si puote e quel che non si puote lo si fa lo stesso.
>
Leonardo Serni
wrote:
>> Guarda: se ti poni una domanda cosi', ho idea che tu debba ripensare l'
>> intera architettura.
>Che architettura in un sito di 5 pagine?
Anche in un sito con una pagina sola, Eucli'. Architettura non e' la
Facolta' :-)
>Ho solo creato un form che invia via sms i suoi dati e siccome devo
>decidere se lasciare utente e pwd di accesso all'invio nella pagina del
>form (pagina in html)
L'autenticazione deve avvenire lato utente. Se proprio ti vuoi sdare
implementi l'autenticazione via 401.
Anche perche' solo cosi' puoi essere sicuro di chi usa il servizio.
>stesso? e quindi in una pagina "criptata" potrebbero restare pi� al
>sicuro
Non credo, il browser vede la form in chiaro, e quindi l'invio lo fa
altrettanto in chiaro. Apri Firebug e leggi tutte cose, facile.
>> Cominciamo da principio: cos'e' che vorresti fare?
>BHO! :P
Ecco, in questo caso allora il mio suggerimento e' non farlo: ti vai
solo a cercare delle rogne.
Prima decidi bene cosa vuoi fare, dopo con carta e penna simuli come
dovrebbero funzionare le cose... e poi lo fai vedere a qualcun altro
per vedere se nota qualche baco che a te e' sfuggito.
Andare un po' a casaccio, te lo rid�o, vuol dire cercare guai. Penso
sia inutile che ti faccia esempi: la memoria non ti fara' difetto.
Euclide
> Anche in un sito con una pagina sola, Eucli'. Architettura non e' la
> Facolta' :-)
A si ed allora che cosa c'� da pensare?
Non si fa tutto di seguito a seconda di dove esce? :P
>
> L'autenticazione deve avvenire lato utente. Se proprio ti vuoi sdare
> implementi l'autenticazione via 401.
>
L'utente non deve mica inviare la mia password al sito di invio sms.
> Anche perche' solo cosi' puoi essere sicuro di chi usa il servizio.
>
Questa � una idea, a parte comunque che sia una problematica marginale
in quanto si fa il controllo con telefonata per conferma dell'ordine.
>
> Non credo, il browser vede la form in chiaro, e quindi l'invio lo fa
> altrettanto in chiaro. Apri Firebug e leggi tutte cose, facile.
>
Comunque non si decripta tanto facilmente e quindi non vedo perch� uno
si debba prendere la briga, oltre al fatto che la passwrod coincide con
il buono che verr� cambiato settimanalmente.
>
> Ecco, in questo caso allora il mio suggerimento e' non farlo: ti vai
> solo a cercare delle rogne.
>
Sicuro? Finora sono 25 anni che vado tranquillo perch� finora si faceva
di tutto e solo per gioco in internet.
> Prima decidi bene cosa vuoi fare, dopo con carta e penna simuli come
> dovrebbero funzionare le cose... e poi lo fai vedere a qualcun altro
> per vedere se nota qualche baco che a te e' sfuggito.
>
Non saprei a chi farlo vedere, visto esempi di programmatori e
sistemisti in ambianti ad alto rischio sicurezza che non gliene frega il
meno, tipo anche essere riusciti a prendere 950MB di virus con emule.
> Andare un po' a casaccio, te lo rid�o, vuol dire cercare guai. Penso
> sia inutile che ti faccia esempi: la memoria non ti fara' difetto.
>
Guarda che a rompere le palle a twitter non sono stato io!
E se glielo chiedi nemmeno l'arbazzani, in ogni caso � che ho grosse
problematiche a sopravvivere che di certe cose non ho tempo di
occuparmene, server pi� o server meno si campa lo stesso.
p.s.: Ho letto il raccontino dove alla fine del moenod invece restano
solo i CED ma � solo fantasie e nemmeno fantascienza.
Paperino
> Euclide
>>> Cominciamo da principio: cos'e' che vorresti fare?
>>BHO! :P
> Ecco, in questo caso allora il mio suggerimento e' non farlo: ti vai
> solo a cercare delle rogne.
E poi ti leghi ad un solo browser, pure proprietario.
Bye, G.
Leonardo Serni
wrote:
/SBAM
Leonardo Serni
wrote:
>> Anche in un sito con una pagina sola, Eucli'. Architettura non e' la
>> Facolta' :-)
>A si ed allora che cosa c'� da pensare?
>Non si fa tutto di seguito a seconda di dove esce? :P
Dato che siamo sotto Natale ti risparmio l'ovvia battuta, ma in futuro
evita :-)
>> L'autenticazione deve avvenire lato utente. Se proprio ti vuoi sdare
>> implementi l'autenticazione via 401.
>L'utente non deve mica inviare la mia password al sito di invio sms.
No, ovviamente no; l'utente deve inviare la PROPRIA password a una web
app sul tuo sito, che convalida tutto e invia LEI la roba al sito SMS.
Se mandi la tua password, comunque criptata, a un browser (client) che
poi la reinvia al sito SMS, sei fottuto... magari non subito, ma entro
un paio di giorni..
>> Non credo, il browser vede la form in chiaro, e quindi l'invio lo fa
>> altrettanto in chiaro. Apri Firebug e leggi tutte cose, facile.
>Comunque non si decripta tanto facilmente e quindi non vedo perch� uno
>si debba prendere la briga
Eh gia' <sospiro>... come usare un open relay non pubblicizzato: a chi
vuoi che interessi?
Vabe'. Tu continua ad andare avanti alla cazzo; quando incontrerai chi
ti far� il proverbiale culo come uno sbadiglio di ciuco, mi raccomando
prenditela con quel bischero del sottoscritto che non e' stato chiaro,
non t'ha detto le cose per filo e per segno, e non ti ha nemmeno fatto
fare il ruttino dopo.
>Sicuro? Finora sono 25 anni che vado tranquillo perch� finora si faceva
>di tutto e solo per gioco in internet.
...ho il sospetto che non apparteniamo allo stesso Universo :-)
>> Andare un po' a casaccio, te lo rid�o, vuol dire cercare guai. Penso
>> sia inutile che ti faccia esempi: la memoria non ti fara' difetto.
>Guarda che a rompere le palle a twitter non sono stato io!
>E se glielo chiedi nemmeno l'arbazzani
*LOL*
>p.s.: Ho letto il raccontino dove alla fine del moenod invece restano
>solo i CED ma � solo fantasie e nemmeno fantascienza.
Mi sa che - a parte tutto il resto - mi confondi con qualcun altro.
Euclide
Euclide
>>> L'autenticazione deve avvenire lato utente. Se proprio ti vuoi sdare
>>> implementi l'autenticazione via 401.
>
>> L'utente non deve mica inviare la mia password al sito di invio sms.
>
> No, ovviamente no; l'utente deve inviare la PROPRIA password a una web
> app sul tuo sito, che convalida tutto e invia LEI la roba al sito SMS.
>
Questa � anche una idea da implementare ma intanto sar� per il carrello
di ordine ed in secondo luogo invia alla web app che si trova sul mio
sito ma in una altro dominio.
Letto sulla autenticazione 401 e non mi interessa pi� di tanto per
l'invio del form in quanto non devo autenticare l'utente, sarebbe causa
di ritardi e perdite di ordini anche se casomai mi evita un cumulo di
scherzi da parte di bacarozzi vari.
Dovrei cercare poi di implementare l'autenticazione o la registrazione
utente per il carrello ecomemrce, che epr ora � solo carrello e lo devo
ancora integrare per l'invio dell'SMS.
> Se mandi la tua password, comunque criptata, a un browser (client) che
> poi la reinvia al sito SMS, sei fottuto... magari non subito, ma entro
> un paio di giorni..
>
Io la pwd la mando alla web app che la manda al sito web di invio sms,
quindi i problemi che dici saranno anche cavoli del sito di invio sms
per l'autenticazione.
Anche se non gli frega se invio 10 o 100 anzi se mi fregano ed inviano
100 sms dal mio account a loro sta pure bene. :P
>
> Eh gia' <sospiro>... come usare un open relay non pubblicizzato: a chi
> vuoi che interessi?
>
Uffa, io con il tuo codice non sono riuscito a decriptare inoltre la
fatica che farebbero sarebbe solo di farmi cambiare pwwd se vedo che ci
sono invii non autorizzati, inoltre dovrebbero avere tutte le specifiche
per usare il mio account da un altro sito, mentre direttamente gli manca
la pwd, forse mettere il cell. di consegna sms nel programmino php
invece che prenderlo in request mi aiuta a non fare inviare sms ad
altri? Tipo autoricariche 3?
>
> Mi sa che - a parte tutto il resto - mi confondi con qualcun altro.
>
Non mi hai segnalto tu il raccontino, ma di certo la fantascienza �
sempre avanti!
Leonardo Serni
wrote:
>> No, ovviamente no; l'utente deve inviare la PROPRIA password a una web
>> app sul tuo sito, che convalida tutto e invia LEI la roba al sito SMS.
>Questa � anche una idea da implementare ma intanto sar� per il carrello
>di ordine ed in secondo luogo invia alla web app che si trova sul mio
>sito ma in una altro dominio.
Meglio ancora. L'importante pero' e' che il canale App/App _NON_ sia nel
controllo del client.
In PHP puoi mandare la roba facilmente con una readfile, o con curl. Non
e' molto diverso farlo in ASP(X).
>Letto sulla autenticazione 401 e non mi interessa pi� di tanto per
>l'invio del form in quanto non devo autenticare l'utente, sarebbe causa
>di ritardi e perdite di ordini anche se casomai mi evita un cumulo di
>scherzi da parte di bacarozzi vari.
Esatto. Non puoi decidere se perdere o no del tempo; lo perderai in ogni
caso. Puoi decidere se perderlo nel blindare l'applicazione, o perderlo,
non saprai mai quanto ogni volta, n� quante volte, quando l'applicazione
ti fara' casino.
>Dovrei cercare poi di implementare l'autenticazione o la registrazione
>utente per il carrello ecomemrce, che epr ora � solo carrello e lo devo
>ancora integrare per l'invio dell'SMS.
Per vari motivi, non ti posso dire il perch� o il percome un'"ecommerce"
senza autenticazione sia (tranne casi particolarissimi) un suicidio. Ma,
fidaty ;) f.d., lo e'.
>Io la pwd la mando alla web app che la manda al sito web di invio sms,
>quindi i problemi che dici saranno anche cavoli del sito di invio sms
>per l'autenticazione.
Loro non si fanno problemi: intanto paghi gli SMS, e poi se il contenuto
e' ralla sono cavoli tuoi. A quel punto ti tocca verificare con l'utente
e passarci da "improvvisato".
Dammi retta: piglia il vizio di impiegare, a progettare le cose, *almeno
il doppio* del tempo che ti ci vorra' per realizzarle.
Ti risparmierai tanti disagi.
Dammi retta, palle.
Euclide
> Per vari motivi, non ti posso dire il perch� o il percome un'"ecommerce"
> senza autenticazione sia (tranne casi particolarissimi) un suicidio. Ma,
> fidaty ;) f.d., lo e'.
>
spesso molto klimitati ed allora il cliente prende ci� che arriva, poi
se ha altro da spende si integra.
Il mi collaboratore se deve fare un ecommerce da zero, anche piccolo,
comincia a pensare dai migliaia ed il cliente invece pensa nell'ordine
delle decine, io cerco di accontentare tutti e faccio ci� che posso.
Credo che non ti si debba dire le ore di tempo che ci si perde e quanto
si vorrebbe essere pagati ad ora impiegata.
Alla fine anche la proposta a percentuale sugli ordini per arrivare a
coprire i costi (anche a pizze) ha fatto storcere il naso in quanto
vuole una cosa sua.
Cooper
"Gigino" <gi...@dagigi.info> ha scritto nel messaggio
news:4b359876$0$9753$6e1e...@read.cnntp.org...
> Ma le pagine criptate con programmi tipo HTML uard o HTML Guardian �
> possibile poi decriptarle?
>
> Ad esempio per modifiche in caso perdo la pagina originale?
>
renderne pi� difficile la lettura (anche se l'utilizzo reale � ben altro).
Una pagina criptata necessit� di una chiave di codifica e una di decodifica
che ovviamente nelle pagine web non sussistono.
Tuttavia le chiavi di codifica e decodifica sussistono per la connessione
che pu� essere appunto protetta ergo criptata.
Non confondiamo quindi una pagina web "criptata" che poi � codificata da una
connessione protetta (criptata) ergo non in chiaro.
Cooper.