Technicznie nieznacznie, tak. Ale:

• Byłoby to zabezpieczenie przez zapomnienie, co jest złym pomysłem
• To nie zwiększa zaufania do Twojego produktu
• Bardzo łatwo byłoby dowiedzieć się, co robi, zajęłoby to tylko trochę czasu
• Tłumacz Google, możesz po prostu używać bezsensownych nazw, to i tak niewiele by pomogło
• Utrudniłoby to konserwację
• Bardzo utrudniłoby przeprowadzanie audytów, ponieważ audytorzy mogą nie rozumieć języka

Biorąc pod uwagę wszystkie kwestie, prawdopodobnie nigdy nie warto to.

Nie byłoby to znacznie bezpieczniejsze. Inżynierowie odwrotni są często zmuszani do pracy z systemami, które nie mają nienaruszonych żadnych oryginalnych nazw (oprogramowanie produkcyjne często usuwa nazwy symboli), więc przyzwyczajają się do pracy z nazwami wygenerowanymi przez komputer. Przykład zaczerpnięty z Wikipedii, fragmentu dekompilowanego kodu C, który jest często widywany:

  struct T1 * ebx; struct T1 {int v0004; int v0008; int v000C;}; ebx->v000C - = ebx->v0004 + ebx->v0008;  

Ludzie, którzy są przyzwyczajeni do pracy z tego rodzaju reprezentacją, nie dają się zwieść używaniu zmiennych i tym podobnych którym nadano nieistotne nazwy. To nie jest specyficzne dla skompilowanego kodu , a użycie języka C było tylko przykładem. Inżynierowie odwrotni są ogólnie przyzwyczajeni do zrozumienia kodu, który nie jest intuicyjny. Nie ma znaczenia, czy używasz JavaScript, czy Java, czy C. Nie ma nawet znaczenia, czy analizują one tylko komunikację z samym API. Inżynierowie odwrotni nie dadzą się zwieść używaniu losowych lub nieistotnych nazw zmiennych lub funkcji.

Niezupełnie - wszystkie funkcje wbudowane nadal będą w języku angielskim, więc ustalenie, co będą reprezentować zmienne, nie wymagałoby większego wysiłku. Może to trochę spowolnić, ale biorąc pod uwagę, że ludziom nadal udaje się odtworzyć kod z pojedynczymi zmiennymi znakowymi w każdym miejscu lub który został przepuszczony przez obfuskatory, zamiana języka używanego dla zmiennych i funkcji oznacza po prostu wykonanie operacji znajdź-zamień kiedy już zorientujesz się, do czego służy jedna z twoich zmiennych, powtarzaj, aż będziesz wystarczająco rozumieć

To jest ochrona poprzez zaciemnienie i opóźni dedykowanego atakującego o całe pięć minut.

Jeśli chcesz zmylić atakującego, nazwanie rzeczy ich przeciwieństwem lub czymś niezwiązanym miałoby ten sam skutek. Twoja funkcja „Utwórz użytkownika” mogłaby więc nazywać się „BakeCake”. Teraz możesz sobie odpowiedzieć, ile daje Ci to bezpieczeństwa. Właściwie byłoby to bezpieczniejsze , ponieważ nie można go pokonać za pomocą zwykłego słownika.

Tak, na początku mogłoby to zmylić, ale jedno spojrzenie na system w działanie i wszystko staje się natychmiast krystalicznie jasne.

Twój system MUSI być sam w sobie bezpieczny. Jeśli polega na tym, że javascript po stronie użytkownika przekazuje parametr z wartością „open sesame”, robisz to źle.

Powinieneś napisać program w języku, który jest dla Ciebie wygodniejszy (np. od biegłości programisty, spójności z bazą kodu, a nawet z terminami, których używasz).

Inne odpowiedzi wskazywały już, że tak naprawdę nie zapewnia to bezpieczeństwa. Jeśli chcesz stworzyć bezpieczny program, zamiast martwić się o to, że potencjalni hakerzy będą mogli łatwo odczytać Twój kod i poznać tajną dziurę, prawdopodobnie powinieneś bardziej zadbać o to, aby był czytelny dla osób dokonujących audytu .

Jeśli istnieje parametr funkcji o nazwie nonce i komentarz mówiący o tym, w jaki sposób zapewniamy, że jest on unikalny w żądaniach, ale nie jest wysyłany w żądaniu, możesz być całkiem pewien, że to pomyłka. Faktycznie, posiadanie łatwego do odczytania kodu zmniejszy szanse na upuszczenie / opróżnienie tego parametru (w końcu wszystko działało bez niego...), a jeśli tak się naprawdę stanie, ułatwi to innym programiści zauważają problem.

(Osoby trzecie też mogą Cię o tym poinformować. Prawdopodobnie więcej osób przyjrzy mu się przypadkowo niż tych, którzy faktycznie próbują go rozwiązać. Losowy napastnik najprawdopodobniej zacznij od uruchomienia zautomatyzowanego narzędzia i miej nadzieję, że cokolwiek znajdzie.)

TL; DR: stwórz czytelny kod. Dla ludzi, którzy powinni się tym zająć. W razie wątpliwości powinieneś wybrać ten, o którym większość ludzi wie.

Może to nawet pogorszyć sytuację, utrudniając konserwację systemu.

Weź skrajny przykład inspirowany historią i komunikuj się między frontem a zapleczem w Navajo. Kiedy (nie jeśli) musisz załatać kod, musisz albo:

• pracować z tym, co dla ciebie jest nonsensem (z dodatkową szansą na błędy / literówki plus praca na nie -intuicyjny kod) lub
• zatrudnij / utrzymuj programistów biegle w Navajo (rzadka i potencjalnie kosztowna kombinacja umiejętności, prawdopodobnie niemożliwa do znalezienia wykonawcy)

Chciałbym również zauważyć, że w większości przypadków javascript po stronie klienta skrypt w takiej postaci, w jakiej został opracowany (ze znaczącymi nazwami zmiennych itp.) byłby „zminimalizowany” w celu zwiększenia wydajności na kliencie (mniejszy rozmiar pliku do pobrania).

W ramach tego większość nazw zmiennych jest zredukowanych do pojedynczych znaków, a jak najwięcej białych znaków jest usuwanych. Staje się to tak samo nieczytelne, jak cokolwiek innego, co możesz napisać.

Chciałbym również zauważyć, że chrome (na przykład) ma metody, które pobierają plik „mniej czytelny dla człowieka” taki jak ten i „ładnie go drukują”, co znacznie ułatwia zrozumienie, co się dzieje.

Krótko mówiąc, ludzki język, którego używasz do pisania kodu po stronie klienta, naprawdę nie robi dużej różnicy.

Jeśli wierzyć środkom masowego przekazu, to większość hakerów to Rosjanie, Chińczycy i Koreańczycy z północy, więc już działają na „przeszkodzie” związanej z koniecznością hakowania zachodnich systemów w język obcy. Dlatego jeśli nie wybierzesz czegoś niesamowicie niejasnego, jak w filmie Windtalkers , nie zrobi to dla nich żadnej różnicy. Jednak dodatkowy wysiłek oznacza mniej czasu na znajdowanie i naprawianie błędów, więc jeśli już, ta strategia zmniejszyłaby Twoje bezpieczeństwo .

W kilku odpowiedziach (słusznie) wskazano, że jest to „bezpieczeństwo przez zaciemnienie”, które w rzeczywistości nie jest formą bezpieczeństwa. Najbezpieczniej jest założyć, że atakujący ma w pełni opatrzony adnotacjami kod źródłowy, który siedzi przed nim podczas zajętego ataku.

Oprogramowanie jest „bezpieczne”, gdy zna wszystko, co można wiedzieć przed żądaniem / transakcją / sesja jest publicznie znana ORAZ nie ma to wpływu na faktyczne bezpieczeństwo produktu.

Należy założyć, że kod źródłowy jest powszechnie znany, choćby dlatego, że niezadowoleni pracownicy nie są brani wycofać się i strzelić, gdy zostaną zakończeni. Lub, jak się często mawia, „Jedynym sposobem, aby dwoje ludzi zachowało tajemnicę, jest śmierć jednej z nich”. Zatem każda „wiedza specjalna”, która jest ukrywana przez jakiekolwiek zaciemnianie, musi być traktowana jako „wiedza ogólna”, gdy tylko zostanie wytworzona.

W istocie bezpieczeństwo jest niczym innym jak „ mówiąc, co robisz, i robiąc to, co mówisz ”. Analiza bezpieczeństwa - audyt kodu i schematy oceny formalnej, takie jak przeprowadzane w ramach Common Criteria - wymaga, aby mechanizmy wykonywania akcji były dobrze udokumentowane i aby wszystkie przejścia z jednego bezpiecznego stanu do drugiego bezpiecznego stanu były możliwe tylko wtedy, gdy wszystkie wymagania zadowoleni. Jednym z zagrożeń związanych z wszelkiego rodzaju zaciemnianiem jest to, że te wymagania są zasłonięte przez sprytne kodowanie - zobacz przykład niepowodzenia funkcji „create_user ()”, ponieważ jest to „potajemnie” metoda „usuń użytkownika”, „zmień nazwę użytkownika” lub inna metoda. Aby zobaczyć rzeczywisty przykład tego, jak trudna jest zmiana nazwy w mózgu, dostępne są testy on-line, w których należy odczytać nazwę koloru, która jest drukowana na ekranie w innym kolorze. Na przykład słowo „CZERWONY” zapisane niebieską czcionką spowoduje, że pewna liczba osób powie „NIEBIESKI” zamiast „CZERWONY”.

To może być nieistotne. Rozważ scenariusz, w którym piszesz (np. Po włosku zamiast po angielsku), ale większość Twoich klientów jest we Włoszech, naturalnie włoskojęzyczni hakerzy mają wyższą motywację / korzyści z zaatakowania Cię.

W tym W scenariuszu kodowanie w innym języku nie przynosi żadnego efektu lub może nawet ułatwić hakowanie.