Visualizzazione dei risultati da 1 a 6 su 6

Discussione: sicurezza e Form

  1. #1
    Utente di HTML.it
    Registrato dal
    Jul 2005
    Messaggi
    642

    sicurezza e Form

    salve,
    una domnda per intenditori:

    se io, in un input utente impongo che non venga inserito il tag <form> per motivi di sicurezza,
    e' possibile che un acker inserisca un tag personalizzato del tipo <myForm>, e che poi sviluppi un browser che interpreti il tag <myForm> come se fosse il tag <form>?

    Se si, c'e' un modo per impedire cio' senza rinunciare alla formattazione html del testo immesso come ad esempio avverrebbe con Server.HtmlEncode.

  2. #2
    2 strade per rendere sicura la tua appz:

    1) interpretare solo i tag "elementari" (b, a, p, div, ecc..) eliminando quelli pericolosi (script, form)

    2) mettere un codice di verifica sotto forma di immagine che l'utente è obbligato ad inserire. Questo ovviamente non impedisce l'inserimento di tag potenzialmente pericolosi ma rende più "pensato" l'inserimento del testo da parte del visitatore. In questo modo solo chi vorrà veramente partecipare scriverà qualcosa di coerente con il sito trattato.


  3. #3
    Ciao,
    permettimi di dire che l'interpretazione di MyForm in Form è decisamente improbabile.

    Se stai pensando ad attacchi di tipo XSS allora ricordati che quasi tutti i tag sono vulnerabili.. (un esempio su tutti il tag <img>), ed in questo caso puoi provare a trovare la library di microsoft anti XSS.

    Se allo stesso tempo fai delle operazioni sui db ricordati di usare stored e SqlParameters.
    Inoltre a tua discrezione, puoi iniziare a valutare l'idea di utilizzare delle regEx per filtrare il contenuto del testo.

    ps Zofm : scusami, ma il sistema che tu hai suggerito viene impiegato per evitare l'inserimento automatico del testo da parte di robots. Dal fatto che spesso gli attacchi di sul server sono condotti in manuale (persona), dubito che possa essere una soluzione "mirata alla protezione dei dati". La classificherei come un sistema di protezione per interventi non graditi.

  4. #4
    Originariamente inviato da Jc_
    ps Zofm : scusami, ma il sistema che tu hai suggerito viene impiegato per evitare l'inserimento automatico del testo da parte di robots. Dal fatto che spesso gli attacchi di sul server sono condotti in manuale (persona), dubito che possa essere una soluzione "mirata alla protezione dei dati". La classificherei come un sistema di protezione per interventi non graditi.
    Si, certo. Volevo far capire che oltre ad essere un ottimo strumento anti-spam, un controllo del genere può sempre scoraggiare più in fretta chi sta cercando eventuali buchi di sicurezza dell'applicazione.


  5. #5
    Utente di HTML.it
    Registrato dal
    Jul 2005
    Messaggi
    642
    riguardo ai regex e stored procedured sono gia state implementate, il punto è che mi sono accorto che non sono sufficienti vi faccio un esempio:


    <script ?>alt("ciao")</script>


    come vedete questo è un tag di fantasia che tuttavia viene interpretato dai browser come se fosse un vero e proprio script!!!

    Quanti di voi lo sapevano?

    Ora il punto è : se anche questo tag di fantasia viene interpretato come un tag script, allora nessun tag è sicuro nenache i vari [b][i] e compagnia bella,

    perche' chi si intende di programmazione puo' fare un browser che interpreta il tag [b] come se fosse un tag <form> o <script> e a quel punto accadono i disastri.

  6. #6
    scusami ma non ti seguo proprio, posso scrivere un browser che interpreta il codice html o js in un certo modo.. perfetto. Ma resti comunque lato client. Il server ti dice "A" e tu recepisci "B". Il codice maligno, in questo caso, sarebbe B, non di certo A.

    Facendo la submit del valore B al server, questo verrebbe intercettato e trattato come codice maligno.

    Veramente non capisco.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.