In caso di chiusura di una struttura di sondaggio

Stai parlando di sondaggi sui siti web, presumo? Il "qual è la tua lingua preferita, C #, Java o COBOL?" digitare sondaggi? Se è così, è interessante.

Normalmente sono d'accordo con la risposta di Simon che se aprire la fonte rivela delle lacune, non è mai stato sicuro per cominciare.

Tuttavia , per questo tipo di app .. è probabile che no, non era sicuro all'inizio e non può essere facilmente creato così. Il problema è che sto scommettendo che hai il requisito per le persone di essere in grado di venire sul sito e votare nel sondaggio, non è richiesta alcuna registrazione. E tu anche hai il requisito incompatibile secondo cui le persone dovrebbero poter votare solo una volta.

Quindi qualunque cosa tu faccia .. c'è una scappatoia. Controllo degli indirizzi IP? Il visitatore che vuole imbrogliare sa usare un proxy. Biscotti? Il visitatore che vuole imbrogliare sa cancellare i suoi cookie. Aprire la fonte rende banale vedere come imbrogliare.

Ma detto questo ... è comunque banale. Non ci vuole molto tempo per provare le alternative e vedere quale consente più voti. Semplicemente non è possibile rendere sicuro questo tipo di sondaggio anonimo, quindi potresti anche open source e almeno ottenere gli eyeball che individuano i bug!

Infatti, essere open source ti aiuta ad essere più sicuro .

I personally believe that when a program began as closed source and is then first made open source, it often starts less secure for any users (through exposure of vulnerabilities), and over time (say a few years) it has the potential to be much more secure than a closed program. If the program began as open source software, the public scrutiny is more likely to improve its security before it's ready for use by significant numbers of users, but there are several caveats to this statement (it's not an ironclad rule). Just making a program open source doesn't suddenly make a program secure, and just because a program is open source does not guarantee security:

• First, people have to actually review the code. This is one of the key points of debate - will people really review code in an open source project? All sorts of factors can reduce the amount of review: being a niche or rarely-used product (where there are few potential reviewers), having few developers, and use of a rarely-used computer language. Clearly, a program that has a single developer and no other contributors of any kind doesn't have this kind of review. On the other hand, a program that has a primary author and many other people who occasionally examine the code and contribute suggests that there are others reviewing the code (at least to create contributions). In general, if there are more reviewers, there's generally a higher likelihood that someone will identify a flaw - this is the basis of the "many eyeballs" theory. Note that, for example, the OpenBSD project continuously examines programs for security flaws, so the components in its innermost parts have certainly undergone a lengthy review. Since OSS/FS discussions are often held publicly, this level of review is something that potential users can judge for themselves.
   
  One factor that can particularly reduce review likelihood is not actually being open source. Some vendors like to posture their "disclosed source" (also called "source available") programs as being open source, but since the program owner has extensive exclusive rights, others will have far less incentive to work "for free" for the owner on the code. Even open source licenses which have unusually asymmetric rights (such as the MPL) have this problem. After all, people are less likely to voluntarily participate if someone else will have rights to their results that they don't have (as Bruce Perens says, "who wants to be someone else's unpaid employee?"). In particular, since the reviewers with the most incentive tend to be people trying to modify the program, this disincentive to participate reduces the number of "eyeballs". Elias Levy made this mistake in his article about open source security; his examples of software that had been broken into (e.g., TIS's Gauntlet) were not, at the time, open source.

• Second, at least some of the people developing and reviewing the code must know how to write secure programs. Hopefully the existence of this book will help. Clearly, it doesn't matter if there are "many eyeballs" if none of the eyeballs know what to look for. Note that it's not necessary for everyone to know how to write secure programs, as long as those who do know how are examining the code changes.

• Third, once found, these problems need to be fixed quickly and their fixes distributed. Open source systems tend to fix the problems quickly, but the distribution is not always smooth. For example, the OpenBSD developers do an excellent job of reviewing code for security flaws - but they don't always report the identified problems back to the original developer. Thus, it's quite possible for there to be a fixed version in one system, but for the flaw to remain in another. I believe this problem is lessening over time, since no one "downstream" likes to repeatedly fix the same problem. Of course, ensuring that security patches are actually installed on end-user systems is a problem for both open source and closed source software.

Another advantage of open source is that, if you find a problem, you can fix it immediately. This really doesn't have any counterpart in closed source.

In short, the effect on security of open source software is still a major debate in the security community, though a large number of prominent experts believe that it has great potential to be more secure.

Guarda Linux ...

L'argomento secondo cui l'open source "ridurrà la sua sicurezza e validità mentre le persone rivelano scappatoie" è completamente invalido. Un prodotto sicuro non dovrebbe avere scappatoie quindi quando è reso open source non ci dovrebbero essere scappatoie da rivelare.

Se il tuo prodotto presenta scappatoie che verrebbero rivelate rendendolo open source che non è sicurezza, questo è solo nascondere la tua mancanza di sicurezza dietro il tuo compilatore. Potresti farla franca per un po ', ma alla fine qualcuno decodificherà il tuo codice e troverà una di quelle scappatoie (di cui forse non sapevi nulla)

Mi fiderei di un prodotto di sicurezza open source molto più di quanto mi fiderei di uno closed source.

L'esperto di sicurezza Bruce Schneier riassume bene:

If I take a letter, lock it in a safe, hide the safe somewhere in New York, then tell you to read the letter, that's not security. That's obscurity. On the other hand, if I take a letter and lock it in a safe, and then give you the safe along with the design specifications of the safe and a hundred identical safes with their combinations so that you and the world's best safecrackers can study the locking mechanism -and you still can't open the safe and read the letter - that's security.

Bruce Schneier - Applied Cryptography

Leggi attentamente Will Open Sourcing Stack Overflow Distruggi il nostro modello aziendale? - mentre lo Stack Overflow non è uguale al tuo quadro di sondaggio, dovrebbe darti più informazioni sulle visualizzazioni di molte altre persone.

Un paio di pensieri che mi sono venuti in mente che non conosco la risposta a me stesso ...

1. Solo perché qualcuno invia il codice al progetto, potrebbe non essere abbastanza buono / accettato / usato. Open-source non rende automaticamente il codice migliore.
2. Allo stesso modo, non so quale sia l'assorbimento medio per gli sviluppatori che danno una mano con il codice. Non ci possono essere orde di sviluppatori che contribuiscono alla fonte? (anche se hai solo bisogno di 1 o 2 per fare una differenza sostanziale).
3. Immagino che non ci sia nulla che ti impedisca di aprire il framework, ma tu esegui una versione personalizzata per la tua azienda che ha altre funzionalità / sicurezza integrate.
4. La tua azienda può rimanere anonima / non pubblicizzare che è dietro il framework? E dove il framework è installato / live - mascherare che è un framework particolare? (Considera wordpress e come uno dei consigli di sicurezza è quello di nascondere il meta tag che dice "Wordpress versione 2.3").
5. Devi anche parlare con il tuo capo / ufficio legale perché il tuo contratto di lavoro potrebbe dire qualcosa in base al quale la proprietà intellettuale di qualsiasi cosa tu crei al lavoro è di proprietà del tuo datore di lavoro, e open-sourcing del codice che ha avuto origine la compagnia potrebbe farti atterrare in acqua calda.