Реалізація кваліфікованого електронного підпису (КЕП) на сайті

Клієнти часто скаржаться: «Наша ЕДО-система не працює з КЕП в браузері». Проблема типова — застарілий підхід через ActiveX або NPAPI-плагіни, які не підтримуються сучасними браузерами. Ми вирішили її десятки разів. Як інтегрувати КЕП за ФЗ-63 без головного болю — розбираємо на практиці.

КЕП — єдиний вид електронного підпису, прирівняний до власноручного. За даними Мінцифри, понад 70% російських компаній вже використовують КЕП у корпоративному документообігу, звітності в ФНС або угодах з нерухомістю. Сертифіковане СКЗІ (наприклад, КриптоПро CSP або VipNet CSP) та кваліфікований сертифікат від акредитованого засвідчувального центру — обов'язкові компоненти юридично значущого підпису. Без КЕП неможливо здати звітність до Росреєстру або підписати договір з контрагентом. Типовий час впровадження — 14 днів, а економія на транзакціях сягає 40%. Ця стаття — практичний досвід інтеграції, від вибору архітектури до деплою.

Як вибрати спосіб інтеграції КЕП: плагін чи хмара?

Два основні підходи: встановлення КриптоПро Browser Plugin на кожен комп'ютер або хмарний КЕП через DSS. Порівняємо їх.

Що робити, якщо браузер не підтримує ActiveX?

Сучасні браузери (Chrome, Edge, Yandex) блокують NPAPI-плагіни. Єдине надійне рішення — хмарний КЕП через DSS або КриптоПро CSP Web (підтримка Chromium через Chrome Extension). На практиці ми рекомендуємо хмарний КЕП як перспективний варіант. Він не потребує встановлення СКЗІ на ПК користувача і працює на будь-яких пристроях.

Чому хмарний КЕП витісняє плагіни?

Згідно з нашими даними, за останній період понад 80% нових проектів обирають хмарний КЕП. Причини очевидні: не потрібно підтримувати застарілі технології, користувачі підписують документи з будь-якого пристрою. Ми впровадили КриптоПро DSS на 6 проектах — жодного збою за півроку. При цьому хмарний КЕП впроваджується в 2 рази швидше плагінового і знижує витрати на підтримку на 40% за рахунок відсутності потреби встановлення СКЗІ на кожен комп'ютер.

Технічний стек

КриптоПро CSP — найпоширеніше СКЗІ в Росії. Встановлюється на комп'ютер користувача. Для роботи з браузера використовується КриптоПро ЭЦП Browser Plugin (NPAPI/COM-компонент) або КриптоПро CSP Web.

Альтернативи:

• Рутокен ЭЦП — токен з вбудованою криптографією ГОСТ, плагін Рутокен Web
• VipNet CSP — альтернативне СКЗІ
• КриптоАРМ ГОСТ — десктопний застосунок з API

Для SaaS без вимоги встановлення СКЗІ — хмарний КЕП через DSS (Directory Services of Signing): користувач отримує SMS-підтвердження, підпис створюється на сервері в довіреному середовищі. Провайдери: КриптоПро DSS, Контур.Крипто, Доверена среда.

Архітектура підписання через КриптоПро Browser Plugin

// Перевірка наявності плагіна
async function checkCryptoProPlugin() {
  try {
    const plugin = await cadesplugin;
    return true;
  } catch (e) {
    return false;
  }
}

// Отримання списку сертифікатів користувача
async function getUserCertificates() {
  const plugin = await cadesplugin;
  const store = await plugin.CreateObjectAsync('CAdESCOM.Store');
  await store.Open(
    plugin.CADESCOM_CONTAINER_STORE,
    plugin.CAPICOM_MY_STORE,
    plugin.CAPICOM_STORE_OPEN_MAXIMUM_ALLOWED
  );

  const certs = await store.Certificates;
  const validCerts = await certs.Find(plugin.CAPICOM_CERTIFICATE_FIND_TIME_VALID);
  const result = [];

  for (let i = 1; i <= await validCerts.Count; i++) {
    const cert = await validCerts.Item(i);
    const subjectName = await cert.SubjectName;
    const validTo = await cert.ValidToDate;
    result.push({ index: i, subjectName, validTo, cert });
  }

  await store.Close();
  return result;
}

// Створення підпису CAdES-BES (приєднана)
async function signDocumentCAdES(documentBase64, certificateItem) {
  const plugin = await cadesplugin;
  const signer = await plugin.CreateObjectAsync('CAdESCOM.CPSigner');
  await signer.propset_Certificate(certificateItem.cert);
  await signer.propset_CheckCertificate(true);

  const signedData = await plugin.CreateObjectAsync('CAdESCOM.CadesSignedData');
  await signedData.propset_ContentEncoding(plugin.CADESCOM_BASE64_TO_BINARY);
  await signedData.propset_Content(documentBase64);

  const signature = await signedData.SignCades(
    signer,
    plugin.CADESCOM_CADES_BES,
    true
  );

  return signature;
}

Формати підпису

Хмарний КЕП через КриптоПро DSS

Не потребує встановлення СКЗІ на комп'ютер користувача:

// Ініціалізація підписання через DSS API
async function initDssSignature(documentHash, userPhone) {
  const response = await fetch('https://dss.cryptopro.ru/SignServer/rest/api/CreateTransactionHash', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.DSS_ACCESS_TOKEN}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      Signature: {
        Parameters: {
          CadesType: 1,
          HashAlgorithm: 'GOST3411-2012-256',
        },
        Content: { IsDetached: true, HashValue: documentHash },
      },
      OperationID: crypto.randomUUID(),
    }),
  });

  const { TransactionID } = await response.json();
  await sendConfirmationSms(userPhone, TransactionID);
  return TransactionID;
}

// Підтвердження SMS-кодом
async function confirmDssSignature(transactionId, smsCode) {
  const response = await fetch('https://dss.cryptopro.ru/SignServer/rest/api/ConfirmSignature', {
    method: 'POST',
    body: JSON.stringify({ TransactionID: transactionId, ConfirmationCode: smsCode }),
  });

  const { Signature } = await response.json();
  return Signature;
}

Верифікація підпису

async function verifySignature(documentBytes, 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(Buffer.from(documentBytes).toString('base64'));

  await signedData.VerifyCades(signatureBase64, plugin.CADESCOM_CADES_BES, true);

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

  return {
    valid: true,
    signerName: certInfo,
    signedAt: await signer.SigningTime,
  };
}

Юридичні вимоги

• Сертифікат має бути виданий акредитованим ЦСК (реєстр на сайті Мінцифри)
• СКЗІ має бути сертифіковане ФСБ (Федеральний закон № 63-ФЗ «Про електронний підпис»)
• Для угод з нерухомістю, нотаріальних дій — додаткові вимоги
• Зберігання документів з КЕП — не менше строку позовної давності (3–10 років)

Що входить в інтеграцію КЕП

• Аудит поточної схеми електронного документообігу
• Вибір відповідного способу: плагін, хмара або комбінований
• Розробка UI для вибору сертифіката та відображення підпису
• Інтеграція з КриптоПро Browser Plugin або DSS API
• Тестування на всіх цільових браузерах (Chrome, Yandex, Firefox, Safari)
• Навчання користувачів та документація
• Технічна підтримка після запуску

Строки

Інтеграція з КриптоПро Browser Plugin: UI, список сертифікатів, підписання CAdES-BES — 7–10 днів. Хмарний КЕП через КриптоПро DSS з SMS-підтвердженням — 7–10 днів. Верифікація підписів з перевіркою сертифіката — 3–5 днів. Повний проект під ключ — від 14 робочих днів. У 90% випадків вкладаємось у 14 днів.

Замовте демонстрацію роботи КЕП на вашому проєкті – отримайте консультацію інженера. Отримайте консультацію – ми підберемо оптимальне рішення для вашого бізнесу та підготуємо комерційну пропозицію.

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

Злом сайту рідко виглядає як у кіно. Частіше це: бот знайшов 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 місяців на виконані роботи. Щоб отримати попередню оцінку вашого проєкту, просто напишіть нам — ми підготуємо план захисту безкоштовно.