Захаваны файл — яшчэ не праверанае спампоўванне
Перад публікацыяй або выкарыстаннем праверце, што спампоўванне праз проксі змяшчае патрэбны файл, а не старонку аўтэнтыфікацыі ці няпоўны адказ.
Гіпатэтычны report.xlsx мае памер 8 KB і адкрываецца як старонка ўваходу. Праграма паспяхова захавала файл, але так і не атрымала патрэбную табліцу. Імя файла выбіраецца лакальна; яно не сведчыць пра тое, што прыйшло.
Зрабіце прыёмку асобным крокам перад публікацыяй часовага спампоўвання:
- Патрабуйце паспяховай перадачы і чаканага статусу адказу. Захавайце памылку, а не лічыце байты, запісаныя да яе, поўнымі.
- Параўнайце змест з чаканым тыпам файла. Старонка ўваходу або фільтра можа вярнуць 200. Content-Type можа быць няправільным, а HTML-прэфікс у табліцы — гэта папярэджанне, якое трэба даследаваць. Файл, што пачынаецца з радка стану HTTP, сведчыць хутчэй пра неапрацаваны адказ.
- Праверце поўныя захаваныя байты супраць даверанай кантрольнай сумы або подпісу, калі яны ёсць. Публікаваць або выкарыстоўваць канчатковы файл праграма павінна толькі пасля праходжання патрэбных праверак.
Вылічэнне хэша без чаканага значэння вызначае толькі тыя байты, якія вы атрымалі. Непадпісаная кантрольная сума, атрыманая праз той жа недавераны шлях, можа мець тую ж слабасць, што і файл; выкарыстоўвайце незалежнае даверанае чаканне.
Будзьце ўважлівыя і да параўнання памеру. HTTP-кліент можа дэкадаваць кадаванне змесціва падчас чытання, таму даўжыня атрыманага файла можа цалкам легітымна адрознівацца ад загалоўка, які апісвае закадаванае паведамленне. Параўноўвайце чаканне выдаўца з тым прадстаўленнем, якое фактычна захавана.
Калі спроба няўдалая, захавайце часовы вынік толькі для свядомага працягу або адкіньце яго. Пакіданне няпоўных байтаў у канчатковым шляху прымушае наступную праграму здагадвацца, ці яны прыдатныя.