uniemożliwić atak XSS poprzez adres URL (PHP)

Question

staram się uniknąć ataku XSS poprzez url
URL: http://example.com/onlineArcNew/html/terms_conditions_1.php/%22ns=%22alert%280x0000DC%29 Próbowałem

var_dump(filter_var('http://10.0.4.2/onlineArcNew/html/terms_conditions_1.php/%22ns=%22alert%280x0000DC%29', FILTER_VALIDATE_URL)); 

i inne url_validation za pomocą wyrażenia regularnego, ale nie działał w ogóle. powyższy link pokazuje wszystkie informacje, ale moja funkcja css i niektóre funkcje skryptów java nie działają. zaproponuj najlepsze możliwe rozwiązanie ...

Answer 1

Jeśli używasz MVC, spróbuj rozszyfrować wszystkie wartości przed routingiem i użyj stript_tags(), aby pozbyć się tych złych nastrojów. I jak mówią doktorzy, sprawa nie powinna wpływać na nic.

Jeśli nie, utwórz funkcję narzędzia i wykonaj to samo podczas pobierania zmiennych z identyfikatora URI. Ale w żadnym wypadku nie jestem ekspertem od XSS, więc to może być tylko część sztuczki.

Od Janis Peisenieks

Answer 2

Krok 1: Ucieczka Output dostarczone przez użytkowników

Jeśli chcesz zawierać dane w obrębie strony, które zostało dostarczone przez użytkowników, ucieczka wyjście. I na tej uproszczonej liście będziemy trzymać się jednej prostej operacji ucieczki: HTML koduje dowolne <,>, &, ",". Na przykład PHP udostępnia funkcję htmlspecialchars(), aby wykonać to typowe zadanie.

Krok 2: Zawsze używaj XHTML

przeczytać XSS strategii zapobiegania OWASP, a okaże się, że ochrona przed wstrzyknięciem wymaga znacznie więcej wysiłku, jeśli używasz nienotowanych atrybutów w kodzie HTML. Natomiast w przytoczonych atrybutach dane ucieczkowe stają się tym samym procesem, który jest potrzebny do uniknięcia danych dotyczących treści w tagach, czyli operacji ucieczki, którą już omówiliśmy powyżej. Dzieje się tak dlatego, że jedynym kłopotliwym pod względem skradającym się strukturalnie istotną treścią w kontekście cytowanego atrybutu jest końcowy cytat.

Oczywiście twój znacznik nie musi być XHTML, aby zawierać cytowane atrybuty. Jednak strzelanie i sprawdzanie poprawności w stosunku do XHTML ułatwia testowanie, czy wszystkie atrybuty są cytowane.

Krok 3: Tylko Pozwól wartości alfanumerycznych danych w CSS i JavaScript

Musimy ograniczyć dane, które pozwolą od użytkowników, będzie emitowany w ciągu CSS i JavaScript sekcji strony do alfanumerycznych (np regex jak [a-zA-Z0-9] +) typy i upewnij się, że są używane w kontekście, w którym rzeczywiście reprezentują wartości. W JavaScript oznacza to, że dane użytkownika powinny być wyprowadzane tylko w cudzysłowach przypisanych do zmiennych (np. Var userId = "ALPHANUMERIC_USER_ID_HERE";). W CSS oznacza to, że dane użytkownika powinny być wyprowadzane tylko w kontekście dla wartości właściwości (np. {color: #ALPHANUMERIC_USER_COLOR_HERE;}.) To może wydawać się Draconian, ale, hej, to powinien być prosty samouczek XSS

Teraz, dla jasności, należy zawsze sprawdzać dane użytkownika, aby upewnić się, że spełnia on Twoje oczekiwania , nawet dla danych, które są wyprowadzane w tagach lub atrybutach, jak we wcześniejszych przykładach. Jest to szczególnie ważne w przypadku regionów CSS i JavaScript, ponieważ złożoność możliwych struktur danych bardzo utrudnia zapobieganie atakom XSS.

Powszechne dane, które użytkownicy mogą chcieć dostarczyć do JavaScript, takie jak Facebook, YouTube i Twitter ID, mogą być używane z uwzględnieniem tego ograniczenia.Można również zintegrować atrybuty kolorów CSS i inne style.

Krok 4: URL zakodować URL string zapytanie Parametry

Jeśli dane użytkownika jest wysyłany w parametrze URL łącza ciąg kwerendy, upewnij się, że URL kodowania danych. Ponownie, używając PHP jako przykładu, możesz po prostu użyć funkcji urlencode(). Teraz wyjaśnijmy to i przejrzyjmy kilka przykładów, ponieważ widziałem wiele zamieszania w odniesieniu do tego konkretnego punktu.

Musi URL zakodować

Poniższy przykład wyświetla dane użytkownika, które muszą być zakodowane URL, ponieważ jest on używany jako wartość w ciągu kwerendy.

http://site.com?id=USER_DATA_HERE_MUST_BE_URL_ENCODED”>

nie może URL zakodować

Poniższy przykład wysyła dane dostarczane przez użytkownika dla całej zawartości. W takim przypadku dane użytkownika powinny zostać zastąpione standardową funkcją escape (kodowanie HTML dowolne <,>, &, ","), a nie kodowane przez URL. Kodowanie URL tego przykładu prowadziłoby do zniekształconych linków.

Answer 3

Spróbuj użyć FILTER_SANITIZE_SPECIAL_CHARS Zamiast

$url = 'http://10.0.4.2/onlineArcNew/html/terms_conditions_1.php/%22ns=%22alert%280x0000DC%29'; 

// Original 
echo $url, PHP_EOL; 

// Sanitise 
echo sanitiseURL($url), PHP_EOL; 

// Satitise + URL encode 
echo sanitiseURL($url, true), PHP_EOL; 

Wyjście

http://10.0.4.2/onlineArcNew/html/terms_conditions_1.php/%22ns=%22alert%280x0000DC%29 
http://10.0.4.2/onlineArcNew/html/terms_conditions_1.php/"ns="alert(0x0000DC) 
http%3A%2F%2F10.0.4.2%2FonlineArcNew%2Fhtml%2Fterms_conditions_1.php%2F%26%2334%3Bns%3D%26%2334%3Balert%280x0000DC%29 

Funkcja Używane

function sanitiseURL($url, $encode = false) { 
    $url = filter_var(urldecode($url), FILTER_SANITIZE_SPECIAL_CHARS); 
    if (! filter_var($url, FILTER_VALIDATE_URL)) 
     return false; 
    return $encode ? urlencode($url) : $url; 
}