Co każdy programista powinien wiedzieć o bezpieczeństwie? [zamknięte]

Zasada # 1 Bezpieczeństwa dla programistów: nie rzucaj własnych

O ile nie jesteś ekspertem od bezpieczeństwa i / lub kryptografem, Zawsze używaj dobrze zaprojektowanej, dobrze przetestowanej i dojrzałej platformy bezpieczeństwa, frameworka lub biblioteki, aby wykonać pracę za Ciebie. Te rzeczy przez lata były przemyślane, łatane, aktualizowane i badane zarówno przez ekspertów, jak i hakerów. Chcesz zyskać te zalety, a nie odrzucać je, próbując odkryć koło na nowo.

Teraz to nie powiedzieć, że nie musisz się niczego uczyć o bezpieczeństwie. Z pewnością musisz wiedzieć wystarczająco dużo, aby zrozumieć, co robisz i upewnić się, że prawidłowo używasz narzędzi. Jeśli jednak kiedykolwiek zaczniesz pisać swój własny algorytm kryptograficzny, System Uwierzytelniania, środek dezynfekujący itp., zatrzymaj się, zrób krok w tył i zapamiętaj regułę # 1.

Każdy programista powinien umieć pisać kod exploita.

Nie wiedząc, w jaki sposób systemy są wykorzystywane, przypadkowo zatrzymujesz luki w zabezpieczeniach. Wiedza o tym, jak łatać kod jest absolutnie bez znaczenia, chyba że wiesz, jak testować swoje łatki. Bezpieczeństwo to nie tylko kilka eksperymentów myślowych, musisz być naukowy i przetestować swoje eksperymenty.

Bezpieczeństwo to proces, a nie Produkt.

Wielu zdaje się zapominać o tej oczywistej rzeczy.

Proponuję przejrzeć CWE / SANS TOP 25 najniebezpieczniejszych błędów programistycznych. Został on zaktualizowany na rok 2010 z obietnicą regularnych aktualizacji w przyszłości. Na 2009 dostępna jest również wersja.

Z http://cwe.mitre.org/top25/index.html

The 2010 CWE/SANS Top 25 Most Dangerous Programming Errors to lista najbardziej rozpowszechnionych i krytycznych błędów programistycznych, które mogą prowadzić do poważnych luk w oprogramowaniu. Często są łatwe do znalezienia i łatwe do wykorzystania. Są one niebezpieczne, ponieważ często pozwalają atakującym całkowicie przejąć oprogramowanie, ukraść dane lub uniemożliwić działanie oprogramowania.

The Top 25 list to narzędzie edukacji i świadomości, które pomaga programistom zapobiegać rodzajom luk w zabezpieczeniach, które nękają przemysł oprogramowania, poprzez identyfikowanie i unikanie zbyt powszechnych błędów, które występują przed wprowadzeniem oprogramowania. Klienci oprogramowania mogą korzystać ta sama lista, aby pomóc im poprosić o bezpieczniejsze oprogramowanie. Naukowcy zajmujący się bezpieczeństwem oprogramowania mogą wykorzystać Top 25, aby skupić się na wąskim, ale ważnym podzbiorze wszystkich znanych słabości zabezpieczeń. Wreszcie, menedżerowie oprogramowania i dyrektorzy IT mogą korzystać z listy Top 25 jako miernika postępu w swoich wysiłkach na rzecz zabezpieczenia swojego oprogramowania.

Dobrym kursem startowym może być Kurs MIT z Sieci Komputerowych i Bezpieczeństwa . Jedną z rzeczy, które chciałbym zaproponować, to nie zapominać o prywatności. Prywatność, pod pewnymi względami, jest naprawdę fundamentalna dla bezpieczeństwa i nie jest często omawiana w kursach technicznych dotyczących bezpieczeństwa. W tym kursie Możesz znaleźć materiały dotyczące prywatności na temat Etyki i prawa w odniesieniu do Internetu.

Zespół ds. bezpieczeństwa sieci w Mozilli przygotował świetny przewodnik , którego przestrzegamy przy rozwoju naszych Witryn i usług.

Znaczenie bezpiecznych ustawień domyślnych w frameworkach i interfejsach API:

• wiele wczesnych frameworków internetowych nie uciekało domyślnie html w szablonach i miało problemy z XSS z tego powodu
• wiele wczesnych frameworków internetowych ułatwiało łączenie SQL niż tworzenie sparametryzowanych zapytań prowadzących do wielu błędów SQL injection.
• Niektóre wersje Erlang (R13B, może inne) domyślnie nie weryfikują certyfikatów ssl peer i prawdopodobnie istnieje wiele kodów erlang, które są podatne na ataki SSL MITM
• Java XSLT transformer domyślnie pozwala na wykonanie dowolnego kodu Javy. Przez to powstało wiele poważnych błędów bezpieczeństwa.
• interfejsy API XML w Javie domyślnie pozwalają przetwarzanemu dokumentowi na odczyt dowolnych plików w systemie plików. Więcej zabawy:)

Powinieneś wiedzieć o trzech A. uwierzytelnianie, autoryzacja, audyt. Klasycznym błędem jest uwierzytelnienie użytkownika, nie sprawdzając, czy użytkownik jest uprawniony do wykonania jakiejś czynności, aby użytkownik mógł przeglądać prywatne zdjęcia innych użytkowników. Wiele, wiele więcej osób zapomina o audycie, trzeba w bezpiecznym systemie wiedzieć, kto co i kiedy zrobił.

• pamiętaj ,że ty (programista) musisz zabezpieczyć wszystkie części, ale atakujący musi tylko znaleźć jedno załamanie w Twoim pancerzu.
Bezpieczeństwo jest przykładem "nieznanych niewiadomych". Czasami nie będziesz wiedział, jakie są możliwe wady bezpieczeństwa (aż do później).
• różnica między błędem a dziurą bezpieczeństwa zależy od inteligencji atakującego.

Dodałbym:

Jak działają podpisy cyfrowe i certyfikaty cyfrowe]}
• Co to jest sandboxing

Zrozumieć, jak działają różne wektory ataku:

• przepełnienia bufora / niedopełnienia / etc na kodzie natywnym
• social engineerring
• DNS spoofing
• Człowiek-w-środku
• CSRF / XSS et al
• SQL injection
Ataki kryptograficzne (np. wykorzystywanie słabych algorytmów kryptograficznych, takich jak DES)]}
• Program/Framework błędy (np.: ostatnia wada bezpieczeństwa Githuba) ]}

Możesz łatwo wygooglować to wszystko. To da ci dobry fundament. Jeśli chcesz zobaczyć luki w aplikacjach internetowych, istnieje projekt o nazwie Google gruyere , który pokazuje, jak wykorzystać działającą aplikację internetową.

Kiedy budujesz jakiekolwiek przedsiębiorstwo lub własne oprogramowanie, powinieneś po prostu myśleć jak hacker.as wiemy, że hakerzy nie są również ekspertami we wszystkich rzeczach,ale gdy znajdą jakąkolwiek lukę, zaczynają grzebać w niej, zbierając informacje o wszystkich rzeczach i ostatecznie atakując naszą software.so aby zapobiec takim atakom, powinniśmy przestrzegać pewnych znanych zasad, takich jak:

• zawsze staraj się łamać kody(użyj cheatsheets & google rzeczy więcej informacje).
• Bądź aktualizowany pod kątem wad bezpieczeństwa w swojej dziedzinie programowania.
• i jak wspomniano powyżej, nigdy nie ufaj żadnemu typowi wejść użytkownika lub automatycznych.
• używaj aplikacji opensource(ich większość wad bezpieczeństwa jest znana i rozwiązywana).

• bezpieczeństwo owasp
• CERT Security
• SANS Bezpieczeństwo
• netcraft
• SecuritySpace
• openwall
• PHP Sec
• thehackernews (keep update yourself)

Aby uzyskać więcej informacji google o przepływach bezpieczeństwa dostawcy aplikacji.

1. Dlaczego jest ważne.
Chodzi o kompromisy. [1]}kryptografia jest w dużej mierze odwróceniem uwagi od bezpieczeństwa.

Aby uzyskać ogólne informacje na temat bezpieczeństwa, Gorąco polecam lekturę Bruce Schneier . Ma stronę internetową, swój crypto-gram newsletter , kilka książek i zrobił wielewywiadów .

Chciałbym również zapoznać się z inżynierii społecznej (i Kevin Mitnick).

Za dobrą (i dość zabawną) książkę o tym, jak bezpieczeństwo rozgrywa się w realnym świecie, polecam znakomitą (choć trochę przestarzałą) "The Cuckoo' s Egg" by Cliff Stoll.

Sprawdź również listę OWASP Top 10, aby uzyskać kategoryzację wszystkich głównych wektorów ataku/luk w zabezpieczeniach.

Te rzeczy są fascynujące do czytania. Nauczenie się myśleć jak atakujący będzie Cię szkolić, o czym myśleć, gdy piszesz swój własny kod.

Sól i hash haseł użytkowników. Nigdy nie zapisuj ich w postaci zwykłego tekstu w bazie danych.

Po prostu chciałem podzielić się tym dla web developerów:

Security-guide-for-developers
https://github.com/FallibleInc/security-guide-for-developers