Salam, deməli saytda bazaya gedən məlumatları yox, bazadan gələn məlumatları htmlentities($data, ENT_QUOTES | ENT_HTML5, ‘UTF-8’) ilə filterdən keçirib, ekranda çap edirəm. Bəzən elə olur ki, html teqlətindən istifadə etmək lazım gəlir. Məsələn müəyyən uzunluğu keçəndə, arasına
teqi qoyamaq lazım gəlir. Ya da ki, mətn daxilində link, emoji və s. varsa onda onları teqlə əvəzləmək lazım gəlir. (a href=”” img src=”” və s.) Filterdən keçirtdiyim üçün bunu html kodu kimi yox adi mətn kimi çap edir. (‘Salam img src=”smiley.png”‘) Belə bir variantla problemi həll etmək olar: str_replace(“<br>”, ”
“, $data) , amma bir şey var ki, əgər istifadəçi göndərən mətndə elə
teqi olsa (yəni misal üçün kiməsə
teqi haqqında mesaj göndərsə) bu str_replace() metodu ilə əvəzləndiyi üçün adi mətn kimi yox html teqi kimi ekrana çıxacaq. Yəni XSS boşluğu yaranacaq.
Verilmiş cavablar və yazılan şərhlər (5 cavab var)
0
Belə bir alternativ tapdım, daha doğrusu WordPress-in kodlarına baxarkən gördüm :). Deməli, verilənlər bazasına məlumat filterlənib göndərilir və ordan məlumat çəkiləndə artıq məlumatı filterdən keçirmədən ekranada çap edilir. Bu təhlükəsizlik baxımından nə dərəcədə düzgündür?
0
Salam. Dediyiniz çox ümumi təsvirdir, bu işlərin çox xüsusi halları var və hamısı üçün eyni qayda keçərli deyil. Məsləhət görərdim ki, “WordPress – Validating user data” axtarıb rəsmi saytdan tam oxuyasınız bu mövzunu.
escape başqa məntiqdir, validate başqa, sanitize başqa. Esc çıxışda işlədilir, (məsələn esc_html html teqlərə mane olur, esc_attr html atribut formatına salır data-nı, yəni qoymur ki data html atributu korlasın (class=”” )
və.s.
Bazaya məlumat daxil olanda isə Sanitize adlanır. Yəni burada escape və ya php-nin htmlentities, addslashes filan istifadə edilməməlidir. Həm input həm output üçün WordPress-in öz funksiyaları yetərlidir.
Şərh olaraq yazdığınız hal isə xüsusi haldır, bəzən hansısa məlumat saxlanılarkən onun filtersiz istifadəsi normal ola bilər. Yenə deyirəm, bu duruma bağlıdır, bu məsələlərin ümumi qaydası yoxdur. Bəzən saxlanılacaq data ədəddirsə sadəcə (int) funksiyası bəs edə bilər, bütün filter funksiyalarının yerinə təkcə o.
Tam məlumat burada.
Ümumi yanaşmanız isə doğrudur: “Never trust user input” yanaşması.
0
Yox, mən hər hansısa CMS istifadə etmirəm. Kodları özüm yazıram, yəni deməyim odur ki, mən istifadəçidən alınan məlumatları htmlentites metoduyla bazaya yazdırıram.(<b>) Bazadan məkəndə isə heç bir əlavə əməliyyat aparmıram. Yəni, bu təhlükəsizdir mi?
0
Bazadan çəkəndən sonra nə edirsiz bəs? Təzədən decode edib dərc edirsiz hardasa? O halda entities-in mənası nə oldu? Sadəcə mysql-də saxlamaqmı? Axı entities-in mysql ilə əlaqəsi yoxdur.
Mysql tərəfi qorumaq üçün mysqli-nin öz prepare metodundan istifadə etməniz lazımdır.
html ilə bağlı qorumalar üçün, XSS filan məsələlərinə görə isə yaxşı olar ki fərdi yanaşma ilə qurasınız məntiqi. Məsələn strip_tags edib icazəli teqləri saxlayıb qalanları strip edə bilərsizniz bazadan oxuyarkən və ya yazmadan öncə. (məsələn script teqini filter etmək olar).
Sıfırdan düşünməkdənsə hazır class-lar da götürə bilərsiniz github-dan. Lazımi açar sözləri daxil edin, balaca hazır class-lar götürün githubdan. Hansı ki həm girişi həm çıxışı filterləyə bilir lazımi formada.
0
Misal üçün istifadəçi b teqini yazır. Mən onu htmlentities() ilə “&”lt;b”&”gt; halına gətirib yazıram bazaya. Ordan çəkəndə isə adi print ilə çap elətdirirəm.
Sual verin
Cavab verin