Tabullas drošības labākās prakses, lai novērstu pārkāpumus un datu noplūdes

Pēdējoreiz atjaunināts: 20 Aug, 2026

Tabullas drošības labākās prakses izstrādātājiem

Tabulas (izklājlapas) vada mūsdienu biznesa operācijas. No finanšu prognozēm un vadības padomes ziņojumiem līdz lielapjoma lietotāju importam, norēķinu eksportam un mašīnmācīšanās datu kopām, formāti kā .xlsx, .xlsm un .csv ir pamata uzņēmuma darba plūsmām. Šīs vispārējās pieejamības dēļ programmatūras inženieri regulāri raksta kodu, kas paredzēts izveidot, apstrādāt, parsēt, pārveidot un eksportēt izklājlapu failus.

Tomēr izstrādātāji bieži uzskata izklājlapas par nevainīgu tabulveida datu kopu — digitālu plakna teksta faila ekvivalentu. Realitātē mūsdienu izklājlapas ir aktīvas izpildes vides, kas spēj veikt dinamiskas aprēķinus, atrisināt ārējus galapunktus, izsaukt sistēmas makrokomandas un iekļaut patvaļīgus binārus objektus. Ja tās tiek apstrādātas neuzmanīgi, izklājlapu apstrādes cauruļvadi kļūst par izdevīgiem mērķiem Remote Code Execution (RCE), Formula Injection (CSV Injection), Server-Side Request Forgery (SSRF), XML External Entity (XXE) uzbrukumiem un konfidenciālu datu noplūdēm.

Zemāk ir tehniska rokasgrāmata par aizsargājošu inženierijas prakses īstenošanu, strādājot ar izklājlapām visā jūsu programmatūras stekā.

1. Formulas injekcijas neitralizēšana (CSV & Tabullas injekcija)

Formulas injekcija — bieži dēvēta par CSV injekciju — notiek, kad neuzticama lietotāja ievade tiek tieši ierakstīta izklājlapas šūnās bez pienācīgas sanitizācijas.

Kad galalietotājs vai administrators atver ģenerēto failu Microsoft Excel, Google Sheets vai LibreOffice Calc, jebkura šūnas vērtība, kas sākas ar noteiktiem funkcionāliem rakstzīmēm, tiek interpretēta un izpildīta kā aktīva formula, nevis parādīta kā statisks teksts.

Apdraudējumu mehānika

Uzbrucēji izmanto formulas injekciju, lai izpildītu divas galvenās uzbrukumu klases:

1. Datu izvilkšana: Izmantojot tādas funkcijas kā HYPERLINK, lai klusi pievienotu sensitīvus blakus esošās šūnas datus uzbrukuma kontrolētam vaicājuma parametram.
2. Komandu izpilde: Izmantojot Dynamic Data Exchange (DDE) formulas (piemēram, mantotajās konfigurācijās) vai protokola apstrādātāja saites, lai aktivizētu sistēmas bināros failus vai palaistu ļaundabīgus URL.

Bīstamas sākuma rakstzīmes ietver:

• = (Tieša aprēķināšana vai funkcijas izsaukšana)
• + (Formulas pievienošana vai netiešs funkcijas izsaucējs)
• - (Formulas atņemšana vai negatīva prefikss)
• @ (Dinamiski masīva formulas izsaukšana modernajās Excel versijās)
• \t (Tabulācijas rakstzīme) vai \r (Rindas pārvietošanas rakstzīme) (izmanto, lai apietu naīvu filtrus)
• | vai % (Caurvadu operācijas vai čaulas izsaukumi Unix balstītās izklājlapu skatītājās)

Inženierijas aizsardzība

• Rakstzīmju prefiksēšana (Vienkāršās pēdiņas eskapēšana): Ja neuzticama virknes ievade sākas ar =, +, -, @, \t vai \r, pievienojiet virknei sākumā vienkāršu pēdiņu ('). Excel un LibreOffice uzskata sākuma vienkāršu pēdiņu par formatēšanas norādi, liekot šūnai attēlot saturu kā burtisku tekstu, vienlaikus noņemot pēdiņu no redzamā izvades.
• Stingras serializācijas bibliotēkas: Nekad neizveidojiet CSV vai XLSX failus, izmantojot neapstrādātu virkņu interpolāciju (piem., f\"{user_input_1},{user_input_2}\\n\"). Paļaujieties uz pārbaudītām tabulu serializācijas bibliotēkām, kas automātiski pārvalda RFC 4180 atdalītāju eskapēšanu, lauku aptinšanu un pēdiņu dubultošanu.
• Šūnas tipa uzspiešana: Ģenerējot OpenXML (.xlsx) failus programmatiski, skaidri definējiet šūnas datu tipu kā String (vai InlineString), nevis ļaut dzinējam secināt šūnas tipus no vērtībām.

2. Ievades un parsētāju cauruļvadu nostiprināšana

Lietotāju augšupielādētu izklājlapu parsēšana pakļauj aizmugures sistēmas būtiskām parsera līmeņa uzbrukuma virsmām. Mūsdienīgi .xlsx faili ir saspiesti ZIP arhīvi, kas satur savstarpēji atkarīgus XML dokumentus, kas atbilst Open Packaging Conventions (OPC) standartam.

Neuzticama XML parsēšana aizmugurē atver jūsu pakalpojumus klasiskām parsera ekspluatācijām, ja parsera konfigurācija paliek noklusējuma iestatījumos.

Mažināšanas stratēģijas:

• Deaktivēt DTD un ārējās entītijas (XXE aizsardzība): Pārliecinieties, ka jūsu XML dzinējs skaidri aizliedz Document Type Definitions (DTDs) un deaktivē ārējo shēmu izšķirošanu (disallow-doctype-decl = true, resolve-external-entities = false). Ja tas netiek izdarīts, augšupielādētais .xlsx fails var nolasīt lokālos servera failus (piemēram, /etc/passwd) vai izpētīt iekšējos mākoņa pakalpojumus.
• Aizsargāt pret dekompresijas bombām (ZIP bombas): ļaundari lietotāji var iesniegt mazas arhīvus, kas atkompresējoties pārvēršas desmitos gigabaitos atkārtotas XML datu, sabojājot atmiņu un iztukšojot diska vietu. Sekojiet nekompresētajiem baitiem izguvešanas laikā un noteikt stingrus ierobežojumus gan saspiestā arhīva lielumam, gan kopējai atkompresētās atmiņas pēdas apjomam.
• Pieņemiet plūstošus parsētājus: Izvairieties no milzīgu izklājlapu ielādēšanas atmiņā esošās Document Object Model (DOM) reprezentācijās. Lielu partijas importu gadījumā izmantojiet plūstošu, uz SAX balstītu vai segmentētu rindas pa rindai iterāciju, lai saglabātu aizmugures atmiņas patēriņu konstantu.

3. Makro vadība un aktīvā satura sanitizācija

Visual Basic for Applications (VBA) makrosi, OLE (Object Linking and Embedding) kravu dati un iegultie skripti ir daži no visizturīgākajiem uzbrukuma vektoriem darbvirsmas skaitļošanā.

Izstrādātāju labākās prakses:

• Izspēkojiet stingras paplašinājumu politikas: Noraidiet makro-iespējotus failu formātus (.xlsm, .xltm, .xlsb, vai mantoto .xls) jūsu API vārtejā, ja vien nav pārbaudīta, neizmaināma biznesa prasība tos apstrādāt.
• Izspēkojiet tīrus .xlsx formātus: Standarta .xlsx konteineru formāts ir strukturāli izstrādāts bez makro atbalsta. Jebkāds makro kods, kas ietverts .xlsx failā, padara faila formātu nederīgu saderīgajos Office dzinējos.
• Pārbaudiet un noņemiet aktīvās plūsmas: Ja jūsu pakalpojums apstrādā patvaļīgus pielikumus, integrējiet automatizētu sanitizācijas posmu, kas noņem VBA projekta bināros failus (vbaProject.bin), ActiveX vadīklas un iegultos OLE pakotnes, pirms saglabāt failus objektu glabātuvē vai apkalpot tos citiem klientiem.

4. SSRF novēršana galveņu priekšskatījumu un PDF pārveidošanas laikā

Mūsdienīgas uzņēmuma lietojumprogrammas parasti piedāvā dokumentu priekšskatījuma kartes vai automatizētu PDF pārskatu ģenerēšanu. Lai to izdarītu, aizmugurējās sistēmas bieži izmanto bezgalvas biroja komplektus (piem., LibreOffice bezgalvas režīmā) vai bezgalvas pārlūkprogrammas.

Tabulas var saturēt dinamiskas ārējās atkarības, piemēram, saistītas attēlu formulas (=IMAGE("http://internal-host/...")), attālinātas OData saites vai iegultus tīmekļa rāmjus. Kad bezgalvas procesors renderē tabulu, tas var automātiski izgūt šos saistītos resursus, izraisot Server-Side Request Forgery (SSRF).

Aizsardzības dziļuma pasākumi:

• Izolēt konvertēšanas vidi: Palaidiet bezgalvas renderēšanas pakalpojumus izolētos mikro‑konteineros vai īslaicīgās serverless funkcijās, aprīkotas ar minimālām sistēmas privilēģijām.
• Nodrošināt tīkla izolāciju: Novietojiet dokumentu renderēšanas darbiniekus ierobežotās apakštīklās, kurām trūkst maršruta piekļuves jūsu iekšējai VPC, privātajām datubāzēm vai mākoņa metadatu galapunktam (169.254.169.254).
• Atspējot attālo resursu izšķiršanu: Nododiet konfigurācijas karogus savam renderēšanas dzinējam, lai aizliegtu tīkla balstītu aktīvu izšķiršanu (piem., norādot LibreOffice noraidīt ārējo resursu ielādi eksportēšanas procedūrās).

5. Lapu aizsardzība pret patiesu kriptogrāfisko failu šifrēšanu

Viens no visizturīgākajiem pārpratumiem starp produktu komandām ir atšķirība starp Excel iebūvēto darblapas/darbgrāmatas aizsardzību un kriptogrāfisko šifrēšanu.

Ilūzija par “Aizslēgtām” šūnām

Excel iebūvētās funkcijas “Aizsargāt darblapu” un “Aizsargāt darbgrāmatu” ir lietotāja interfeisa līmeņa iespējas, kas paredzētas, lai novērstu neapzinātas izmaiņas biroja darbiniekiem. Tās neizmanto kriptogrāfiskus piekļuves barjeras. Vienkāršs skripts var dažu sekunžu laikā no .xlsx arhīva iekļautajiem XML failiem izņemt darblapas aizsardzības tagus, padarot ierobežojumus bezjēdzīgus pret apzinātu manipulāciju.

Īsta kriptogrāfiskā aizsardzība:

• Transporta un glabāšanas šifrēšana: Saglabājiet sensitīvus izklājlapu eksportus uz kriptētām glabāšanas apjoma vienībām, izmantojot mūsdienīgus standartus (piem., AWS S3 SSE-KMS, Azure Storage Encryption) un pārsūtiet tos stingri, izmantojot TLS 1.3.
• Standarta OpenXML šifrēšana: Ja izklājlapai jābūt paroles aizsargātai izplatīšanai, izmantojiet nozarē standartizētu AES-256 OpenXML šifrēšanu, nevis novecojušo Office XOR šifrēšanu.
• Datu bāzes līmeņa redakcija (RBAC): Pielietojiet lomu balstītu piekļuves kontroli datu bāzes un lietojumprogrammu slāņos pirms izveidot izklājlapu. Ja eksportējošajam lietotājam nav atļaujas skatīt sociālās apdrošināšanas numurus, iekšējās konta ID vai bruto peļņu, izslēdziet šīs kolonnas no vaicājuma pilnīgi. Nekad neatstājiet sensitīvus datus “slēptās” rindās vai kolonnās.

6. Piekļuves kontrole, izplatīšana un audita žurnāli

Tā kā izklājlapas ir pārnēsājamas, pašpietiekamas datnes, tās bieži apiet centrālos perimetra kontroles mehānismus pēc lejupielādes.

Izstrādātāju labākā prakse:

• Pakalpojums caur autentificētiem, īslaicīgiem priekšparakstītiem URL: Nekad neizmetiet ģenerētās izklājlapu eksportus publiski pieejamos krātuvēs. Ģenerējiet laika ierobežotus priekšparakstītus URL (ar derīguma termiņu mazāk nekā 5 minūtes), kas saistīti ar autentificētu un autorizētu lietotāja sesiju.
• Visaptveroša eksporta uzraudzība: Uzskatiet katru eksporta darbību par datu piekļuves notikumu. Reģistrējiet lietotāja ID, nomnieka ID, vaicājuma parametrus, ģenerēšanas laika zīmogu un saņēmēja IP adresi nemainīgā audita žurnālā.
• Metadatu noņemšana: No galīgā dokumenta īpašībām pirms faila piegādes ārējiem klientiem izņemiet iekšējos atkļūdošanas metadatus, lokālos servera failu ceļus, autoru kontus un formulu rediģēšanas vēsturi.

Kopsavilkuma pārbaudes saraksts izstrādātājiem

Biežāk uzdotie jautājumi (BUJ)

Q1. Vai datu eksportēšana uz standarta CSV failu ir pilnīgi droša pret koda izpildi? Nē, jo izklājlapu lietojumprogrammas automātiski interpretē sākuma rakstzīmes, piemēram =, @, + vai -, kā aktīvas formulas, kas var izgūt šūnu saturu vai izsaukt lokālas komandas.

Q2. Vai Excel darblapas parole var tikt izmantota, lai aizsargātu sensitīvus datus no neautorizētiem izstrādātājiem vai lietotājiem? Nē, iebūvētas darblapas un darba grāmatas aizsardzības paroles tikai ierobežo UI līmeņa rediģēšanu un tās var noņemt tieši no pamatā esošajiem XML failiem bez paroles atgūšanas rīkiem.

Q3. Kāds ir drošākais veids, kā novērst XML External Entity (XXE) uzbrukumus, parsējot .xlsx failus? Konfigurējiet savu XML parseri, lai skaidri neļautu iekļautus DTD un atspējotu ārējo shēmu un entītiju izšķiršanu, pirms parsējat arhīva iekšējos XML failus.

Q4. Kāpēc ir bīstami paļauties uz “slēptām kolonnām” eksportētajās izklājlapās, lai paslēptu sensitīvus iekšējos ID vai metriku? Slēptas kolonnas paliek pilnībā klātesošas pamatdatu slēptajā slānī un var tikt atklātas ar vienu klikšķi izklājlapas lietotāja saskarnē vai izlasītas tieši no neapstrādāta faila satura.

Q5. Kā es varu novērst servera puses pieprasījumu viltošanu (SSRF), ģenerējot PDF kopsavilkumus vai sīktēlu priekšskatījumus lietotāju izklājlapām? Izpildiet renderēšanas dzinējus izolētos, tīklu ierobežotos konteineros, kas stingri aizliedz izejošu tīkla piekļuvi privātām apakštīklām un mākoņa metadatu pakalpojumiem.

Skatīt arī

• CSV vs XLSX vs ODS 2026. gadā: Labākais izklājlapu formāts izstrādātājiem
• XLS vs XLSX vs XLSM vs XLSB – Pareiza izklājlapas formāta izvēle
• Kas ir Excel? Galvenā informācija, ko jums jāzina
• Excel failu formāti: XLSX, XLSM, XLS, XLTX, XLTM
• Atšķirība starp XLS un XLSX