Lista kontrolna dla luki w programowaniu witryny sieci Web

Question

Oglądanie Zysków w Internecie było dla mnie dość wykształceniem. Chciałbym sporządzić listę kontrolną różnych vunerability i exploitów wykorzystywanych na stronach internetowych i jakie techniki programowania można wykorzystać do ich obrony.

• Jakie kategorie wibracji?
  • strona zawiesza
  • włamanie do serwera
  • włamanie do logowania cudzych
  • spamu
  • sockpuppeting, meatpuppeting
  • etc ...
• Jakie defensywnych technik programowania ?
• etc ...

Answer 1

Od Open Web Application Security Project:

1. OWASP Top Ten Luki (pdf)
2. Dla bardziej boleśnie wyczerpującej listy: Category:Vulnerability

W pierwszej dziesiątce są:

1. Przekrój skrypty strony (XSS)
2. wady wstrzykiwań (wstrzyknięcie SQL injection skrypt)
3. Złośliwe wykonanie plik
4. Niepewne bezpośrednim przedmiotem odniesienia
5. Cross-site request forgery (XSRF)
6. wyciek informacji i niewłaściwej obsługi błędów
7. łamany uwierzytelniania i zarządzania sesją
8. Niepewne przechowywania kryptograficzny
9. Niepewne komunikacji
10. Failu ponownie ograniczyć dostęp do adresu URL

Answer 2

SQL injection

Answer 3

XSS (Cross Site Scripting) ataków

Answer 4

Oczywiście przetestować każde pole w poszukiwaniu luk:

• SQL - Ucieczka ciągi (np mysql_real_escape_string)
• XSS
• HTML jest drukowany z pól wejściowych (dobry znak XSS zazwyczaj)
• nic innego thatis nie w konkretnym celu, że pole zostało stworzone dla

Szukaj nieskończonej pętli (jedyną rzeczą pośredni (jeśli dużo osób znalazło to przypadkowo), które naprawdę mogą zabić serwer).

Answer 5

Łatwo nadzorować i łatwo naprawić: odkażanie danych otrzymanych od strony klienta. Sprawdzanie rzeczy takich jak ";" może pomóc w zapobieganiu wstrzykiwania złośliwego kodu do twojej aplikacji.

Answer 6

I sekundę informacji OWASP jako wartościowego zasobu. Następujące elementy mogą być interesujące, a także, w szczególności wzory Atak:

• CERT Top 10 Secure Coding Practices
• Common Attack Pattern Enumeration and Classification
• Attack Patterns
• Secure Programming for Linux and Unix
• A Taxonomy of Coding Errors that Affect Security
• Secure Programming with Static Analysis Presentation

Answer 7

G'day,

Dobrym narzędziem do analizy statycznej dla bezpieczeństwa jest FlawFinder napisane przez Davida Wheelera. Wykonuje dobrą robotę, szukając różnych exploitów bezpieczeństwa, jednak nie zastępuje tego, że ktoś zna dobrze czytany przez twój kod. Jak mówi David na swojej stronie internetowej: "Głupiec z narzędziem jest wciąż głupcem!"

HTH.

okrzyki, Rob

Answer 8

Niektóre techniki zapobiegawcze:

XSS

• Zażycie żadnych parametrów/wejście od użytkownika i nigdy planuję wyprowadzanie go, czy w dzienniku lub stronę internetową, oczyszczaj ją (usuwaj/usuwaj wszystko, co przypomina HTML, cytaty, javascript ...) Jeśli wydrukujesz bieżący adres URL strony w sobie, odkaż się! Nawet drukowanie PHP_SELF, na przykład, jest niebezpieczne. Sanitize! Odblaskowy XSS pochodzi głównie z niesanitalizowanych parametrów strony.

• Jeśli pobierzesz dowolne dane wejściowe od użytkownika i je zapiszesz lub wydrukujesz, ostrzeż je, jeśli wykryje coś niebezpiecznego/nieprawidłowego i poproś o ponowne wprowadzenie danych. IDS jest dobry do wykrywania (np. PHPIDS). Następnie odkaż się przed przechowywaniem/drukowaniem. Następnie, gdy drukujesz coś z magazynu/bazy danych, ponownie odkaż się! Dane wejściowe -> IDS/sanitize -> sklep -> sanitize -> wyjście

• użyj skanera kodu podczas programowania, aby znaleźć potencjalnie podatny kod.

XSRF

• Nigdy nie używaj żądania GET dla destrukcyjną funkcjonalnością, tj usunięcie posta. Zamiast tego tylko akceptuje żądania POST. GET czyni to ekstra łatwym do hakerów.
• Sprawdzanie odsyłającą aby upewnić się, że wniosek pochodzi z witryny nie pracę. Nie jest trudno sfałszować stronę odsyłającą o numerze .
• Użyj losowego skrótu jako tokena, który musi być obecny i ważny w każdym żądaniu, a który wygasa po pewnym czasie. Wydrukuj token w ukrytym polu formularza i sprawdź go po stronie serwera, gdy formularz zostanie opublikowany. Źli faceci musieliby dostarczyć prawidłowy token, aby wykuć prośbę, a jeśli udało im się zdobyć prawdziwy token, musi to nastąpić, zanim wygasną.

SQL injection

• Twój ORM lub db klasy abstrakcji powinien mieć odkażania metod - z nich korzystać, zawsze. Jeśli nie używasz klasy abstrakcji ORM lub db, powinieneś być.

Answer 9

Możesz uzyskać dobre dodatki do firefoxów, aby przetestować wiele wad i usterek, takich jak xss i sql injection z Security Compass. Szkoda, że ​​nie działają na Firefox 3.0. Mam nadzieję, że wkrótce zostaną one zaktualizowane.