- Порезанный
- 17 сентября 2026 г. в 01:57 UTC
- Автор
- Kamo
- Обещать
- 034378d
Последующие меры в отношении 096feaa1 (удостоверения GoDaddy от Организации предоставляются конечной точкой, которая не нуждается в подтверждении). сессия). Сканирование каждой **************** найдено еще четырнадцать колонок Шифротекст без охранника Джексона, кроме пятнадцати, которые всегда были @JsonIgnore: Borrower.ssnEncrypted, Borrower.itinEncrypted Актив / Ответственность / ReoLien.accountNumberEncrypted PlatformOAuthClient / OrgOAuthClient .secretCiphertext и .extraSecretCiphertext **************************** (ТОП-секрет) DevMachineAccount.secretCipher **************************** **************************** .refreshTokenCiphertext Все четырнадцать сейчас @JsonIgnore. Проверено перед изменением, по происхождению/основной части каждого репозитория, который использует эти сущности: каждый зашифрован и расшифрован только на строках, загруженных через JPA, каждая конечная точка отвечает с помощью вручную построенный DTO или карта, органы запроса несут простой текст, который сервер шифрует, и ничто не читает шифротекст обратно из JSON (нет readValue/convertValue в эти типы, нет кэша JSON, нет) передача услуг предприятиям. Для тех десяти сущностей это не закрывает живую утечку - это удаляет Однолинейное изменение (возвращение сущности или вложение ее), которое открыло бы ее. @JsonИгнорировать вместо WRITE ONLY, поэтому орган запроса, связанный с сущностью, также не может установить шифротекст. ******************* утверждает это, размышляя над каждым постоянным типом. JsonbBinding Тест-охрана jsonb-связи: колонка является шифротекстом, когда ее поле говорит шифр или ее колонка говорит CIPHER, ENCRYPTED или ends ENC, и он должен быть @JsonIgnore или WRITE ONLY. Не получилось ровно в эти четырнадцать Перед изменением, и его сопутствующий тест доказывает, что сканирование все еще видит шифротекст, названный четырьмя различными способами.