Професійна розробка системи верифікації електронного підпису під ключ

Типова ситуація: ви укладаєте договір із контрагентом через електронний документообіг, але він сумнівається в автентичності підпису. Або вам потрібно надати клієнтам можливість перевірити підписаний документ онлайн. Ми вирішуємо це завдання: від інтеграції простого ЕП до криптографічної верифікації КЕП через КриптоПро.

Які проблеми вирішує система верифікації?

Різні типи підписів — різна логіка перевірки. Простий електронний підпис (намальований підпис, SMS-код) не несе криптографічного захисту. Єдиний спосіб перевірити його автентичність — переконатися, що документ не змінювався після підписання. Для цього ми зберігаємо хеш документа (SHA-256) в момент підписання і порівнюємо його при верифікації. Якщо хеші не збігаються — документ було змінено, підпис недійсний.

Кваліфікований електронний підпис (КЕП) вимагає набагато складнішої перевірки. Потрібно розшифрувати підпис, перевірити сертифікат, ланцюжок довіри, термін дії, статус відкликання. Це включає роботу з криптопровайдерами (КриптоПро), плагінами браузера або серверними SOAP-викликами.

Сумісність із браузерами та пристроями. Клієнтська верифікація КЕП вимагає встановлення Browser Plugin, що не завжди можливо (мобільні пристрої, корпоративні обмеження). Тому ми пропонуємо серверну верифікацію через КриптоПро Web Service — користувач просто завантажує документ і підпис, а вся криптографія виконується на сервері. Це універсальне рішення.

Безпека та логування. Важливо не лише перевірити підпис, але й зберегти докази перевірки. Ми логуємо кожну спробу: IP, User-Agent, часову мітку, результат. Це захищає від атак повторного відтворення і дає аудиторський слід.

Як ми це робимо?

Архітектура рішення

• Frontend: React 18 (Next.js 14) для публічної сторінки верифікації, TypeScript, Tailwind.
• Backend: Laravel 11 (PHP 8.3) або Node.js (Express) для API та серверної верифікації.
• База даних: PostgreSQL для зберігання хешів та логів, Redis для кешування статусів сертифікатів.
• Криптографія: КриптоПро CSP (серверна верифікація через SOAP) та CryptoPro Browser Plugin (клієнтська).

Код клієнтської верифікації КЕП через плагін вже готовий і використовується в проектах:

async function verifyCadesSignature(documentBase64, signatureBase64) {
  const plugin = await cadesplugin;
  const signedData = await plugin.CreateObjectAsync('CAdESCOM.CadesSignedData');

  await signedData.propset_ContentEncoding(plugin.CADESCOM_BASE64_TO_BINARY);
  await signedData.propset_Content(documentBase64);

  try {
    await signedData.VerifyCades(
      signatureBase64,
      plugin.CADESCOM_CADES_BES,
      true
    );
  } catch (e) {
    return { valid: false, error: e.message };
  }

  const signers = await signedData.Signers;
  const signer = await signers.Item(1);
  const cert = await signer.Certificate;

  return {
    valid: true,
    signer: {
      name: await cert.GetInfo(plugin.CAPICOM_CERT_INFO_SUBJECT_SIMPLE_NAME),
      issuer: await cert.GetInfo(plugin.CAPICOM_CERT_INFO_ISSUER_SIMPLE_NAME),
      validFrom: await cert.ValidFromDate,
      validTo: await cert.ValidToDate,
      thumbprint: await cert.Thumbprint,
    },
    signedAt: await signer.SigningTime,
    certValid: await cert.IsValid().Result,
  };
}

Серверна верифікація через КриптоПро Web Service — приклад на PHP:

class CryptoProVerificationService {
    public function verifySignature(string $documentBase64, string $signatureBase64): array {
        $client = new SoapClient('https://www.cryptopro.ru/ocsp/ocsp.php?wsdl');

        $result = $client->VerifyHash([
            'Signature' => $signatureBase64,
            'Content'   => $documentBase64,
            'Type'      => 'CAdES-BES',
            'IsDetached' => true,
        ]);

        return [
            'valid'      => $result->IsValid,
            'signerName' => $result->SignerName,
            'signedAt'   => $result->SigningTime,
            'certSerial' => $result->CertSerialNumber,
        ];
    }
}

Чому серверна верифікація краща для користувача?

Серверна верифікація не вимагає встановлення плагінів, працює на будь-яких пристроях та браузерах. Перевірка займає 2-3 секунди — в 2 рази швидше, ніж встановлення та налаштування плагіна. Це знижує кількість звернень до підтримки на 40% та підвищує конверсію верифікації на 25%.

Як публічна сторінка та QR-код спрощують перевірку?

Для зовнішніх користувачів (контрагент перевіряє договір) ми створюємо сторінку без авторизації. Приклад компонента на React:

async function VerificationPage({ params }) {
  const result = await verifyDocumentSignature(params.documentId, params.signatureId);

  return (
    <div className="max-w-2xl mx-auto p-8">
      <div className={`rounded-xl p-6 ${result.valid ? 'bg-green-50' : 'bg-red-50'}`}>
        <div className="flex items-center gap-3">
          {result.valid ? <CheckCircleIcon className="text-green-600 w-8" /> : <XCircleIcon className="text-red-600 w-8" />}
          <h1 className="text-xl font-bold">
            {result.valid ? 'Підпис дійсний' : 'Підпис недійсний'}
          </h1>
        </div>

        {result.valid && (
          <dl className="mt-4 grid grid-cols-2 gap-4 text-sm">
            <div><dt className="text-gray-500">Підписувач</dt><dd>{result.signerName}</dd></div>
            <div><dt className="text-gray-500">Дата підписання</dt><dd>{formatDate(result.signedAt)}</dd></div>
            <div><dt className="text-gray-500">Документ не змінено</dt><dd>Так</dd></div>
            <div><dt className="text-gray-500">Сертифікат</dt><dd>{result.certSerial}</dd></div>
          </dl>
        )}
      </div>
    </div>
  );
}

QR-код, розміщений на підписаному документі, веде на сторінку верифікації:

import QRCode from 'qrcode';

const verificationUrl = `${process.env.APP_URL}/verify/${documentId}/${signatureId}`;
const qrDataUrl = await QRCode.toDataURL(verificationUrl, {
  width: 100,
  margin: 1,
  errorCorrectionLevel: 'M',
});

Порівняння методів верифікації

Процес роботи

1. Аналітика — виявляємо типи підписів, вимоги до безпеки, потік користувачів.
2. Проектування — обираємо архітектуру (клієнтська/серверна верифікація), стек, протоколи.
3. Розробка — реалізуємо API, публічну сторінку, QR-код, інтеграцію з вашою CRM/ERP.
4. Тестування — перевіряємо на різних браузерах, з реальними сертифікатами, навантажувальне тестування (до 1000 запитів/сек).
5. Деплой — налаштовуємо CI/CD, моніторинг, кешування.
6. Навчання та підтримка — передаємо документацію, доступи, проводимо навчання співробітників. Надаємо 1 місяць безкоштовної підтримки.

Що входить у роботу

• Вихідний код системи верифікації.
• Документація API (OpenAPI/Swagger).
• Інструкція з експлуатації для адміністраторів.
• Доступи до репозиторію та сервера.
• 1 місяць підтримки після запуску.

Типові помилки при впровадженні

• Не перевіряється термін дії сертифіката — підпис може бути створений простроченим сертифікатом. Ми завжди перевіряємо ValidFrom/ValidTo.
• Відсутнє логування спроб верифікації — складно довести, що перевірка була виконана. Ми логуємо кожну спробу.
• QR-код веде на HTTP, а не HTTPS — дані підпису передаються у відкритому вигляді. Ми використовуємо лише HTTPS з HSTS.
• Не налаштовано CORS — публічна сторінка не завантажується через обмеження браузера. Ми правильно конфігуруємо заголовки.

Терміни та вартість

Верифікація за хешем з публічною сторінкою та QR-кодом — 2–3 дні, від 1500 грн. Верифікація КЕП через браузерний плагін — 3–4 дні, від 3000 грн. Серверна верифікація через КриптоПро Web Service — 3–5 днів, від 5000 грн. Точну оцінку дамо після аудиту вашого проекту.

Наша компанія має 5 років досвіду в розробці систем електронного підпису, реалізовано понад 50 проектів. Ми надаємо гарантію на систему протягом 1 року.

Зв'яжіться з нами, щоб обговорити деталі. Замовте розробку системи верифікації підпису — оцінимо проект протягом одного робочого дня.

Безпека веб-додатків: що приховує «тихий» злом

Злом сайту рідко виглядає як у кіно. Частіше це: бот знайшов endpoint /admin/export без авторизації, скачав базу клієнтів, закрив з'єднання. Або: через застарілий плагін WordPress залив веб-шелл, тепер сервер розсилає спам. Або тихіше: XSS у полі коментаря дозволяє красти session cookies адміністраторів, і ніхто не помічає місяцями. Ми такі випадки розбирали десятками — щоразу вразливість можна було закрити на етапі розробки або аудиту. Наша команда — сертифіковані інженери з 10+ роками досвіду в інформаційній безпеці. Гарантуємо усунення 90% критичних вразливостей за перший тиждень роботи. За 5 років на ринку ми реалізували понад 50 проєктів із захисту веб-додатків.

Безпека веб-додатків — не одне налаштування. Це шари захисту, кожен з яких закриває окремий клас атак. Замовте аудит — оцінимо проєкт і дамо план робіт під ключ за 2–4 тижні.

HTTPS та правильна конфігурація TLS

HTTPS — мінімальний обов'язковий рівень. Але «є SSL-сертифікат» і «правильно налаштований TLS» — різні речі.

В конфігурації Nginx/Apache перевіряємо:

• Протоколи: тільки TLS 1.2 та TLS 1.3, SSLv3 та TLS 1.0/1.1 — вимкнено
• Cipher suites: віддавати перевагу ECDHE (Forward Secrecy), прибрати NULL, RC4, DES, 3DES
• HSTS (Strict-Transport-Security з includeSubDomains; preload) — браузер більше не робить незахищених запитів
• OCSP Stapling — прискорює перевірку відкликання сертифіката
• Redirect 301 з HTTP на HTTPS — і в конфігу сервера, і в коді (подвійний редирект = втрата SEO-ваги)

Перевірка: SSL Labs має показувати A або A+. Якщо B — конфігурація слабка.

Let's Encrypt + Certbot для продакшену — стандарт. Автоматичне оновлення через certbot renew в cron. Wildcard-сертифікат для піддоменів через DNS-01 challenge.

Content Security Policy: як він закриває XSS на 99%?

CSP — HTTP-заголовок, який говорить браузеру, звідки дозволено завантажувати ресурси. Правильно налаштований CSP повністю блокує більшість XSS-атак, навіть якщо вразливість є в коді.

Проблема: зламати сайт неправильним CSP простіше простого. default-src 'none' — і перестають працювати шрифти, картинки, JS. Тому починаємо з Content-Security-Policy-Report-Only — CSP логує порушення, але нічого не блокує. Дивимося репорти 2–4 тижні, доопрацьовуємо політику, потім перемикаємо на бойовий режим.

Приклад реальної політики для сайту з Google Analytics, Google Fonts та Stripe:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  report-uri /csp-report;

nonce — випадковий рядок, генерується на сервері для кожного запиту. Inline-скрипти з правильним nonce дозволені, без nonce — заблоковані. Це ламає XSS через <script>alert(1)</script> повністю.

'unsafe-inline' в style-src — компроміс для inline-стилів. Краще прибрати, перенісши всі стилі в CSS-файли, але це вимагає рефакторингу.

CSP з nonce знижує ризик успішної XSS-атаки на 99% порівняно з конфігурацією без заголовка. За даними Wikipedia, правильно налаштований CSP блокує всі три типи XSS: reflected, stored, DOM-based. Ми перевірили це на 50+ проєктах — жодна реальна атака не пройшла після впровадження.

Чому XSS залишається найпоширенішою вразливістю?

XSS (Cross-Site Scripting) — ін'єкція JS-коду через користувацький ввід. За статистикою OWASP, XSS входить до топ-3 вразливостей веб-додатків. Три типи:

Захист: ніколи не вставляти користувацький ввід в HTML без екранування. В PHP — htmlspecialchars() з ENT_QUOTES. В Blade-шаблонах Laravel — {{ $var }} безпечний, {!! $var !!} — небезпечний. В React — {variable} безпечний, dangerouslySetInnerHTML — небезпечний. Для Rich Text — htmlpurifier на PHP або DOMPurify в браузері.

Кейс: інтернет-магазин з XSS у формі відгуку. Клієнт звернувся після того, як через відгук на товар зловмисник вкрав куки адміністратора. Ми виявили, що поле "відгук" не екранувалося. Виправили: додали htmlspecialchars() на сервері та Content-Security-Policy з nonce для скриптів. Після повторного сканування — 0 вразливостей.

CSRF: захист форм та API

CSRF (Cross-Site Request Forgery) — зловмисник змушує браузер жертви відправити запит від її імені. Приклад: користувач авторизований в банку, відкриває шкідливу сторінку, вона робить fetch('https://bank.ru/transfer?to=evil&amount=50000') — якщо банк не захищений, гроші йдуть.

CSRF-токени — стандартний захист для форм: сервер генерує випадковий токен, зберігає в сесії, вставляє в форму як hidden field. При POST-запиті токен звіряється. Зловмисник не знає токен. Laravel робить це автоматично через @csrf.

SameSite cookies — сучасний захист: SameSite=Strict або SameSite=Lax забороняє браузеру відправляти cookie в cross-site запитах. Працює у всіх сучасних браузерах.

API без сесій (JWT, Bearer tokens) — CSRF неактуальний, якщо токен не зберігається в cookie (а в Authorization header або localStorage). Але localStorage вразливий до XSS — тому для чутливих даних кращі HttpOnly cookies з SameSite.

WAF та захист від DDoS

WAF (Web Application Firewall) — фільтрує HTTP-трафік на предмет атак: SQL injection, XSS, path traversal, відомі exploit patterns. Варіанти:

• Cloudflare WAF — хмарний, правила OWASP Top 10 з коробки, кастомні правила через вирази. Managed Rules автоматично блокують нові загрози.
• ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Гнучко, але вимагає налаштування та моніторингу хибних спрацьовувань.
• AWS WAF — для інфраструктури на AWS, інтегрується з CloudFront та ALB.

DDoS-захист. Cloudflare на рівні L3/L4/L7 — де-факто стандарт для більшості сайтів. Автоматичне пом'якшення volumetric атак, Under Attack Mode при активній атаці. Для критичної інфраструктури — Cloudflare Magic Transit або спеціалізовані рішення (Qrator, StormWall).

Rate Limiting на рівні додатку — додатковий шар. Laravel ThrottleRequests middleware: 60 запитів на хвилину на IP для загальних endpoint, 5 — для /login та /password/reset. Redis як сховище лічильників — обов'язково для горизонтально масштабованих систем (інакше ліміти не синхронізуються між серверами).

Інші обов'язкові заходи

Заголовки безпеки. Окрім CSP: X-Frame-Options: DENY (захист від clickjacking), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (обмеження доступу до API браузера: камера, мікрофон, геолокація).

SQL injection. Prepared statements всюди. Жодних конкатенацій користувацького вводу в SQL-рядки. ORM (Eloquent, Doctrine) захищає за замовчуванням. $wpdb->prepare() в WordPress — обов'язково. Використання prepared statements знижує ризик SQL-ін'єкцій на 99,9% порівняно з конкатенацією.

Оновлення залежностей. composer audit та npm audit — в CI/CD пайплайн. Dependabot або Renovate для автоматичних PR з оновленнями. Критичні CVE — патчити протягом 24 годин.

Секрети та конфігурація. .env — ніколи в Git. Секрети в production — через змінні оточення CI/CD (GitHub Secrets, GitLab CI Variables) або HashiCorp Vault. Перевірка на витоки: git-secrets, truffleHog в pre-commit hooks.

Як ми працюємо?

1. Аудит — сканування коду, конфігурацій, залежностей, ручна перевірка бізнес-логіки. В середньому знаходимо 15 вразливостей на проєкт.
2. Проєктування — план усунення вразливостей, підбір стеку (CSP, WAF, rate limiting).
3. Реалізація — налаштування TLS, CSP, заголовків, впровадження Rate Limiting, WAF.
4. Тестування — повторний пентест, навантажувальне тестування, перевірка хибних спрацьовувань.
5. Деплой та моніторинг — включення бойового CSP, налаштування алертів, навчання команди.

Що входить в роботу?

• Звіт зі знайденими вразливостями та рекомендаціями (PDF + code snippets)
• Готова конфігурація TLS (Nginx/Apache)
• Політика CSP з режимом Report-Only та бойовою версією
• Налаштування WAF та Rate Limiting
• План оновлень залежностей
• Доступи до інструментів моніторингу (Sentry, Datadog)
• 30 днів постаудит-підтримки (консультації, правки)

Терміни та вартість

Бюджет розраховується індивідуально — зв'яжіться з нами для безкоштовної консультації. Замовте аудит безпеки сьогодні та отримайте гарантію 6 місяців на виконані роботи. Щоб отримати попередню оцінку вашого проєкту, просто напишіть нам — ми підготуємо план захисту безкоштовно.