archived-doc-pl/security/errors.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- EN-Revision: ae725a44023db78b9f6e9d2a0baac8c8dc337d38 Maintainer: sobak Status: ready -->
<!-- splitted from ./index.xml, last change in rev 1.66 -->
  <chapter xml:id="security.errors" xmlns="http://docbook.org/ns/docbook">
   <title>Raportowanie błędów</title>
   <para>
    W kwestii bezpieczeństwa PHP, są dwie strony raportowania błędów. Z jednej
    strony jest to przydatne, aby zwiększyć bezpieczeństwo, a z drugiej może być szkodliwe.
   </para>
   <para>
    Standardowa taktyka ataku zakłada profilowanie systemu dostarczając
    mu niepoprawnych danych i sprawdzanie rodzaju i kontekstu zwracanych
    błędów. To pozwala atakującemu na sprawdzenie
    informacji o serwerze i określenie potencjalnych słabości systemu.
    Na przykład, jeśli atakujący pozyskał informacje o stronie
    na podstawie wcześniej wysłanego formularza, to może spróbować nadpisać
    zmienne lub je zmodyfikować:
    <example>
     <title>Atak na zmienne przy użyciu własnego formularza HTML</title>
     <programlisting role="html">
<![CDATA[
<form method="post" action="cel_ataku?username=badfoo&amp;password=badfoo">
<input type="hidden" name="username" value="badfoo" />
<input type="hidden" name="password" value="badfoo" />
</form>
]]>
     </programlisting>
    </example>
   </para>
   <para>
    Zwracane błędy PHP zazwyczaj mogą być całkiem przydatne
    dla programisty, który próbuje znaleźć błąd w skrypcie, wskazując na rzeczy
    jak funkcja lub plik, który zawiódł, w którym pliku PHP nastąpił błąd,
    numer linii z błędem. Te wszystkie informacje
    mogą zostać wykorzystane. Zdarza się, że programiści PHP
    wykorzystują funkcje <function>show_source</function>,
    <function>highlight_string</function> lub
    <function>highlight_file</function> jako narzędzia znajdowania błędów, ale w
    przypadku działającej już strony, mogą one ujawnić ukryte zmienne, niesprawdzoną składnię
    i inne niebezpieczne sytuacje. Szczególnie niebezpieczne jest uruchamianie
    kodu z nieznanych źródeł z użyciem wbudowanych narzędzi debugujących lub używając
    powszechnych technik debugowania. Jeśli atakujący może określić
    jakiej techniki używasz, mogą spróbować zastosować atak brute-force na stronę,
    wysyłając powszechnie znane ciągi znaków związane z debugowaniem:
    <example>
     <title>Wykorzystanie powszechnych zmiennych debugujących</title>
     <programlisting role="html">
<![CDATA[
<form method="post" action="cel_ataku?errors=Y&amp;showerrors=1&amp;debug=1">
<input type="hidden" name="errors" value="Y" />
<input type="hidden" name="showerrors" value="1" />
<input type="hidden" name="debug" value="1" />
</form>
]]>
     </programlisting>
    </example>
   </para>
   <para>
    Niezależnie od metody obsługi błędów, możliwość sprawdzenia
    systemu pod kątem błędów prowadzi do uzbrojenia atakującego
    w więcej informacji.
   </para>
   <para>
    Na przykład sam styl ogólnego błędu w PHP daje informacje, że system
    używa PHP. Jeśli atakujący patrzył na stronę <literal>.html</literal> i
    chciał sprawdzić jej backend (szukając znanych luk w
    systemie), wysyłając złe dane mogą być w stanie odkryć,
    że system został zbudowany przy użyciu PHP.
   </para>
   <para>
    Błąd funkcji może oznaczać, że system używa
    konkretnego silnika baz danych lub dać poszlaki odnośnie tego jak strona
    została zaprogramowana lub zaprojektowana. To pozwala na głębsze zbadanie
    otwartych portów bazy danych lub sprawdzenie konkretnych błędów i podatności
    na stronie. Dostarczając różne próbki błędnych danych atakujący
    może na przykład określić kolejność autoryzacji w skrypcie
    (w oparciu o numer linii w błędach) lub szukać podatności, które
    mogą byc wykorzystane w różnych miejscach skryptu.
   </para>
   <para>
    Błąd systemu plików lub ogólny błąd PHP mogą dać informacje jakie uprawnienia
    ma serwer WWW oraz o strukturze i organizacji
    plików na serwerze. Kod obsługi błędów napisany przez programistę może
    pogorszyć ten problem, prowadząc do prostego wykorzystania wcześniej "ukrytych"
    informacji.
   </para>
   <para>
    Istnieją trzy główne rozwiązania tego problemu. Pierwsze to
    sprawdzenie wszystkich funkcji i próba zapobieżenia większości
    błędów. Drugie to całkowite wyłączenie raportowania błędów
    dla działającego już kodu. Trzecie to wykorzystanie własnych
    funkcji obsługi błędów w PHP. Zależnie od
    Twojej polityki bezpieczeństwa, możesz uznać, że wszystkie trzy metody mają zastosowanie
    w Twojej sytuacji.
   </para>
   <para>
    Jednym ze sposobów wyłapania tej sytuacji przed czasem jest wykorzystanie
    dyrektywy <function>error_reporting</function> w PHP, aby pomóc sobie
    w zabezpieczeniu kodu i odkryciu użycia zmiennych, które może być niebezpieczne.
    Testując swój kod przed wdrożeniem używając poziomu <constant>E_ALL</constant>
    możesz szybko znaleźć obszary, w których zmienne są podatne na zatrucie
    lub ich modyfikację w inny sposób. Gdy jesteś gotowy na wdrożenie,
    powinieneś albo zupełnie wyłączyć raportowanie błędów, ustawiając
    <function>error_reporting</function> na 0, albo wyłączyć pokazywanie
    błędów używając opcji <literal>display_errors</literal> w &php.ini;,
    aby zabezpieczyć swój kod przed sprawdzaniem go przed atakującego. Jeśli zdecydowałeś się
    na drugą opcję, powinieneś też określić ścieżkę do swojego pliku logów używając
    dyrektywy <literal>error_log</literal> i włączyć opcję
    <literal>log_errors</literal>.
    <example>
     <title>Znajdowanie niebezpiecznych zmiennych dzięki E_ALL</title>
     <programlisting role="php">
<![CDATA[
<?php
if ($username) {  // Niezainicjalizowna lub niesprawdzana przed użyciem
    $good_login = 1;
}
if ($good_login == 1) { // Jeśli powyższe sprawdzenie zawiedzie, nie jest inicjalizowana i sprawdzana przed użyciem
    readfile ("/wysoce/wrazliwe/dane/index.html");
}
?>
]]>
     </programlisting>
    </example>
   </para>
  </chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->