作者簡介：

肖文棣，OWASP中國廣東分會負責(zé)人、網(wǎng)安加社區(qū)特聘專家，現(xiàn)任某外企安全架構(gòu)師，負責(zé)應(yīng)用安全設(shè)計、管理和評審等工作。

數(shù)字經(jīng)濟的時代浪潮讓企業(yè)紛紛踏上了數(shù)字化轉(zhuǎn)型的征程，新業(yè)態(tài)與新產(chǎn)業(yè)的涌現(xiàn)，也在催生著新的需求，專業(yè)開發(fā)人員的缺口顯著，數(shù)字化轉(zhuǎn)型不斷加快，傳統(tǒng)的應(yīng)用開發(fā)方式已經(jīng)無法滿足需求，近幾年發(fā)展起來的“低代碼技術(shù)”作為解決企業(yè)數(shù)字化轉(zhuǎn)型以及增強企業(yè)復(fù)原力的有力手段，得到越來越多的關(guān)注，并不斷滲透到各行各業(yè)。

本文將介紹低代碼相關(guān)概念、背景知識、以及低代碼的安全風(fēng)險，最后分享OWASP低代碼安全風(fēng)險Top 10以及相關(guān)預(yù)防措施。

低代碼簡介

百度百科：“低代碼”是一種可視化編程方法，允許企業(yè)不必通過編寫代碼而是通過圖形界面快速搭建應(yīng)用程序。

Gartner定義：低代碼平臺被稱為企業(yè)級低代碼平臺（LCAP），是支持快速應(yīng)用開發(fā)，使用陳述性、高級的編程抽象實現(xiàn)一站式應(yīng)用部署、執(zhí)行和管理的應(yīng)用平臺。

我們可以通過下圖可以形象地了解低代碼：

1.低代碼簡史

低代碼雖然近幾年才火起來，但最早卻是可以追溯到20世紀90年代至21世紀初的編程語言和工具。至于正式的提出，則是由Forrester Research在2014年第一次正式使用“Low-Code”來描述這個市場的，我們這邊也就是這幾年才直譯為“低代碼”，以前都是叫“可視化搭建”。

我們可以了解一下低代碼的發(fā)展歷史：

• 1970年代-1990年代：第四代編程語言（4GL，F(xiàn)ourth-Generation Programming Language）
• 1990年代：快速應(yīng)用程序開發(fā)（RAD，Rapid Application Development）
• 2001：模型驅(qū)動架構(gòu)（MDA，Model-Driven Architecture）
• 2007：移動平臺（Mobile Platform）
• 2016：低代碼與低代碼開發(fā)平臺

2.低代碼為什么流行？

由此可見此領(lǐng)域許多玩家早在幾年前就已經(jīng)存在，那為什么近幾年低代碼賽道被重點關(guān)注，又重新流行起來了呢？歸因于兩個方面：1）技術(shù)成熟度；2）業(yè)務(wù)收益。

我們都知道，任何的技術(shù)都會遵守所謂的“技術(shù)成熟曲線”。從現(xiàn)在來看，支撐低代碼的“老技術(shù)”已經(jīng)通過幾十年的醞釀打磨變得穩(wěn)固，互補的新技術(shù)如云原生、響應(yīng)式web等技術(shù)均慢慢走向成熟，低代碼已經(jīng)快爬到生產(chǎn)力高地；另一方面，由于企業(yè)線上數(shù)字化需求，由過去簡單粗暴的的應(yīng)用架構(gòu)逐漸迭代為多樣化體驗、多粒度服務(wù)的應(yīng)用架構(gòu)，低代碼也就順水推舟，應(yīng)運而生。

3.低代碼的分類

• 無代碼開發(fā)平臺
• 低代碼應(yīng)用平臺（LCAP）
• 多重體驗開發(fā)平臺（MXDP）
• 智能業(yè)務(wù)流程管理套件（iBPMS）

4.低代碼平臺的核心價值

隱私價值

低代碼應(yīng)用程序可以由沒有深厚技術(shù)技能的業(yè)務(wù)人員開發(fā)，因此企業(yè)不能將這些開發(fā)任務(wù)外包給第三方，而是交給內(nèi)部人員，這增強了保密性。

快速價值

由于代碼的主要部分已經(jīng)開發(fā)出來，用戶無需手動編寫代碼，只需直觀配置應(yīng)用程序或進行必要的調(diào)整即可開發(fā)他們需要的應(yīng)用程序。一項調(diào)查顯示，低代碼平臺將開發(fā)速度提高了5~10倍。

降低成本價值

由于開發(fā)周期縮短，無論是由公司開發(fā)還是由外包人員開發(fā)，成本都會降低。

降低復(fù)雜性價值

應(yīng)用程序不是從頭開始構(gòu)建的，其開發(fā)已經(jīng)簡化，因此開發(fā)人員可以更加注重自定義軟件，以滿足用戶的要求。

易維護價值

軟件維護非常重要，需要快速更改軟件，以確保應(yīng)用程序提供的服務(wù)與業(yè)務(wù)需求一致。由于低代碼平臺提供的代碼很少，因此幾乎沒有需要維護的代碼。

貼近業(yè)務(wù)實際價值

低代碼平臺提供了一個簡單、直觀的界面作為應(yīng)用程序部署的開發(fā)環(huán)境。在這種情況下，這些應(yīng)用程序的最終用戶不需要技術(shù)知識，因為他們了解業(yè)務(wù)需求。根據(jù)調(diào)查，44%的低代碼平臺用戶是與技術(shù)人員合作的業(yè)務(wù)用戶。

最小化不穩(wěn)定或不一致的需求價值

在當(dāng)前的軟件開發(fā)過程中，需求之間可能存在沖突，并影響需求變化的應(yīng)用程序。然而，由于業(yè)務(wù)人員也可以參與開發(fā)，使用低代碼意味著可以快速建立最小的可行產(chǎn)品來驗證想法和客戶要求，然后將資源花在客戶可能不注意的特點和功能上。

5.低代碼平臺的能力維度

Gartner共列出了低代碼平臺的11個關(guān)鍵能力維度：

易用性

易用性是標識低代碼平臺生產(chǎn)力的關(guān)鍵指標，是指在不寫代碼的情況下能夠完成的功能的多少。

用戶體驗

這個指標能夠決定最終用戶對開發(fā)者的評價。一般來說，獨立軟件開發(fā)團隊為企業(yè)客戶開發(fā)的項目對用戶體驗的要求會顯著高于企業(yè)客戶自主開發(fā)的項目，開放給企業(yè)的客戶或供應(yīng)商的項目對用戶體驗的要求會高于企業(yè)內(nèi)部用戶使用的項目。

數(shù)據(jù)建模和管理的便利性

這個指標就是通常所講的“模型驅(qū)動”，模型驅(qū)動能夠提供滿足數(shù)據(jù)庫設(shè)計范式的數(shù)據(jù)模型設(shè)計和管理能力。開發(fā)的應(yīng)用復(fù)雜度越高，系統(tǒng)集成的要求越高，這個能力就越關(guān)鍵。

流程與業(yè)務(wù)邏輯開發(fā)能力和效率

這個能力有兩層含義：第一層是指使用該低代碼平臺是否可以開發(fā)出復(fù)雜的工作流和業(yè)務(wù)處理邏輯，第二層是開發(fā)這些功能時的便利性和易用性有多高。一般來說，第一層決定了項目是否可以成功交付，而第二層則決定了項目的開發(fā)成本。無論如何，使用者都應(yīng)關(guān)注第一層。在此基礎(chǔ)上，如果項目以工作流為主，則還應(yīng)該將第二層作為重要的評估指標。

開發(fā)平臺的生態(tài)系統(tǒng)

低代碼平臺的本質(zhì)是開發(fā)工具，內(nèi)置的開箱即用的功能無法覆蓋更多的應(yīng)用場景。此時，就需要基于該平臺的完整生態(tài)系統(tǒng)來提供更深入、更全面的開發(fā)能力。很多開發(fā)平臺都在建立自己的插件機制，這就是平臺生態(tài)的一個典型體現(xiàn)。

編程接口與系統(tǒng)集成能力

為了避免“數(shù)據(jù)孤島”現(xiàn)象，企業(yè)級應(yīng)用通常需要與其他系統(tǒng)進行集成，協(xié)同增效。此時，內(nèi)置的集成能力和編程接口就變得至關(guān)重要。除非確認在可預(yù)期的未來項目不涉及系統(tǒng)集成和擴展開發(fā)，否則開發(fā)者都應(yīng)該關(guān)注這個能力。

支持更先進的架構(gòu)和技術(shù)

系統(tǒng)是否支持更先進的架構(gòu)、清晰的分層，以對接IoT、RPA、機器學(xué)習(xí)等新的技術(shù)？如果開發(fā)者希望自己開發(fā)的應(yīng)用有更長的生命周期，深入了解低代碼平臺產(chǎn)品的架構(gòu)就變得尤為重要。

服務(wù)質(zhì)量

與上一點類似，服務(wù)質(zhì)量也是衡量運行于公有云模式下低代碼平臺的指標。這里的服務(wù)質(zhì)量，除了通常所說的“無故障使用時間”外，還要考慮資源是否支持獨占模式，避免某一個應(yīng)用的高負荷，導(dǎo)致其他應(yīng)用不可用或出現(xiàn)性能劣化。

用戶模型與軟件開發(fā)周期支持

在軟件開發(fā)的生命周期中，除了開發(fā)和交付，還有設(shè)計、反饋、測試、運維等多個環(huán)節(jié)，如系統(tǒng)開發(fā)早期的用戶模型建立和驗證過程通常需要快速模擬和迭代，投入的開發(fā)力量甚至不少于正式開發(fā)。如果一套低代碼平臺具備全生命周期所需的各項功能，將會大大簡化開發(fā)者的技術(shù)棧，進一步提高開發(fā)效率。開發(fā)者所開發(fā)的系統(tǒng)規(guī)模越大，這一能力就越重要。

開發(fā)管理

企業(yè)級軟件的項目規(guī)模通常比較大，而且業(yè)務(wù)更關(guān)鍵，這就對開發(fā)團隊管理提出了更高的要求?，F(xiàn)代軟件開發(fā)中主推的敏捷開發(fā)是否能在低代碼中落地，是衡量開發(fā)管理能力的重要指標。這通常包含代碼庫權(quán)限管理、版本權(quán)限管理、發(fā)布權(quán)限管理等一系列功能，幫助開發(fā)團隊負責(zé)人降低軟件開發(fā)管理過程中的各種人為風(fēng)險。開發(fā)團隊規(guī)模越大，開發(fā)者越應(yīng)當(dāng)關(guān)注這一指標。

安全與合規(guī)

低代碼平臺需要在部署方式、系統(tǒng)安全機制、權(quán)限管理和控制功能等層面發(fā)力，全方位賦能開發(fā)者構(gòu)建安全的、符合企業(yè)規(guī)則的企業(yè)級應(yīng)用。支持本地部署、全SSL數(shù)據(jù)傳輸、密碼強度策略、跨域訪問控制、細粒度的用戶權(quán)限控制等都是該能力的具體體現(xiàn)。大型企業(yè)、特定行業(yè)企業(yè)（如軍工、金融等）通常對該指標的關(guān)注程度會更高一些。

6.國內(nèi)典型的低代碼平臺

2021年11月，F(xiàn)orrester推出《The State of Low-Code Platforms in China》（中國低代碼平臺發(fā)展報告），將中國的低代碼平臺廠商和產(chǎn)品劃分為9大類，并列出了對應(yīng)的代表廠商和產(chǎn)品。

7.低代碼的安全風(fēng)險

低代碼/無代碼應(yīng)用程序的可見性低

低代碼廠商提供的封裝代碼模塊是無法被開發(fā)者檢查測試的，開發(fā)過程類似于“黑箱狀態(tài)”，只能通過低代碼平臺內(nèi)置的組件和流程來大致檢查其內(nèi)在邏輯是否相容。

不安全的代碼

如果低代碼平臺的組件開發(fā)得不夠完善，這將會產(chǎn)生潛在的安全問題。有漏洞的代碼片段不可避免地會被復(fù)制粘貼到其他地方。

另一個要考慮的方面是，許多低代碼和無代碼平臺都是以SaaS方式交付的。SaaS應(yīng)用程序本身存在許多安全風(fēng)險，需要適當(dāng)?shù)闹卫砗蛧栏竦陌踩浴Ｈ绻麤]有對企業(yè)正在使用的SaaS應(yīng)用程序和平臺進行適當(dāng)?shù)膶彶椋赡軙屍錁I(yè)務(wù)面臨不必要的風(fēng)險。

失控的影子IT

由于低代碼和無代碼平臺允許快速創(chuàng)建應(yīng)用程序，即使是那些沒有開發(fā)背景的人員，也可能導(dǎo)致影子IT的泛濫。影子IT發(fā)生在業(yè)務(wù)部門和員工創(chuàng)建應(yīng)用程序并將它們用在企業(yè)內(nèi)部或外部時。這些應(yīng)用程序可能包含企業(yè)和客戶敏感的或受監(jiān)管的數(shù)據(jù)，如果這些應(yīng)用程序在數(shù)據(jù)泄露中受到損害，可能會對企業(yè)產(chǎn)生一系列影響。

業(yè)務(wù)中斷

從業(yè)務(wù)連續(xù)性的角度來看，如果平臺出現(xiàn)中斷，作為服務(wù)交付的低代碼和無代碼平臺可能會中斷業(yè)務(wù)。對于企業(yè)而言，為關(guān)鍵業(yè)務(wù)應(yīng)用程序(包括低代碼和無代碼平臺)建立服務(wù)水平協(xié)議(SLA)非常重要。

8.如何減少低代碼安全風(fēng)險

• 從具有受人尊敬的行業(yè)聲譽的可信賴供應(yīng)商處購買軟件和平臺。
• 確保這些供應(yīng)商擁有第三方認證證書，以代表其內(nèi)部安全實踐和流程。
• 在您的應(yīng)用程序和軟件清單中考慮低代碼和無代碼平臺，以及通過使用它們創(chuàng)建的應(yīng)用程序。
• 保持良好的訪問控制；知道誰在訪問平臺以及他們被允許執(zhí)行哪些活動。
• 實施安全數(shù)據(jù)實踐以了解您的關(guān)鍵數(shù)據(jù)所在的位置，以及使用低代碼和無代碼平臺創(chuàng)建的應(yīng)用程序是否包含敏感數(shù)據(jù)。
• 了解低代碼/無代碼平臺的托管位置。這些平臺是否托管在 AWS、Google 或 Microsoft Azure 等超大規(guī)模全球云服務(wù)提供商 (CSP) 中？或者它們是否托管在傳統(tǒng)的本地數(shù)據(jù)中心中，僅限于沒有物理和邏輯訪問控制？

Owasp低代碼安全風(fēng)險Top10

LCNC-SEC-01：身份冒充

無代碼/低代碼應(yīng)用程序可以冒充任何應(yīng)用程序用戶隱式使用的用戶身份。這為特權(quán)提升創(chuàng)建了一條攻擊路徑，允許攻擊者隱藏在另一個用戶的身份背后來繞過傳統(tǒng)的安全控制.

攻擊場景示例：

場景#1

創(chuàng)客創(chuàng)建一個簡單的應(yīng)用程序來查看數(shù)據(jù)庫中的記錄。創(chuàng)客使用自己的身份登錄數(shù)據(jù)庫，創(chuàng)建嵌入在應(yīng)用程序中的連接。用戶在應(yīng)用程序中執(zhí)行的每個操作最終都會使用創(chuàng)客的身份查詢數(shù)據(jù)庫。惡意用戶利用這一點并使用該應(yīng)用程序查看、修改或刪除他們不應(yīng)訪問的記錄。數(shù)據(jù)庫日志表明所有查詢都是由單個用戶（應(yīng)用程序創(chuàng)客）進行的。

場景#2

創(chuàng)客創(chuàng)建了一個業(yè)務(wù)應(yīng)用程序，允許公司員工用他們的信息填寫表格。為了存儲表單響應(yīng)，創(chuàng)客使用自己的個人電子郵件帳戶。用戶無法知道該應(yīng)用程序?qū)⑺麄兊臄?shù)據(jù)存儲在創(chuàng)客的個人帳戶中。

場景#3

創(chuàng)客創(chuàng)建業(yè)務(wù)應(yīng)用程序并與管理員共享。創(chuàng)客將應(yīng)用程序配置為使用其用戶的身份。除了聲明的目的外，該應(yīng)用程序還使用其用戶的身份來提升創(chuàng)客的權(quán)限。一旦管理員使用該應(yīng)用程序，就會無意中提升了創(chuàng)客的權(quán)限。

預(yù)防措施：

• 提供與外部服務(wù)的連接時，請遵守最低權(quán)限原則。
• 確保應(yīng)用程序使用專用服務(wù)帳戶而不是用戶帳戶。
• 確保應(yīng)用程序在其所有連接中使用單一一致的身份，而不是為每個連接使用不同的身份。
• 確保維護適當(dāng)?shù)膶徲嫺櫍宰R別通過共享連接執(zhí)行的操作背后的參與者。

LCNC-SEC-02：授權(quán)失效

在大多數(shù)無代碼/低代碼的平臺中，服務(wù)連接都是頭等對象。這意味著應(yīng)用程序、其他用戶或整個組織之間的連接。應(yīng)用程序也可以與不應(yīng)訪問其基礎(chǔ)數(shù)據(jù)的用戶共享。

攻擊場景示例

場景#1

創(chuàng)客創(chuàng)建一個連接到他們公司的電子郵件賬戶并且無意中點擊了“與所有人共享”選項。組織中的每個用戶，包括承包商和供應(yīng)商，都可以訪問創(chuàng)客公司的電子郵件賬戶。惡意用戶觸發(fā)“忘記密碼”流程并使用連接來完成該過程，從而獲得對賬戶的控制權(quán)。

場景#2

創(chuàng)客創(chuàng)建一個簡單的應(yīng)用程序來查看數(shù)據(jù)庫中的記錄。該應(yīng)用程序配置成確保每一個用戶只能查看相關(guān)的記錄。但是應(yīng)用程序的配置方式是底層數(shù)據(jù)庫連接與其用戶隱式共享。應(yīng)用程序用戶可以直接使用數(shù)據(jù)庫連接，獲得對所有記錄的完全訪問權(quán)限。

場景#3

管理員使用服務(wù)賬戶將應(yīng)用程序連接到自己的源代碼管理系統(tǒng)（即BitBucket）。配置的服務(wù)賬戶可以不受限制地訪問所有存儲庫，以實現(xiàn)無縫集成。任何內(nèi)部用戶都可以濫用此連接來訪問自己通常無權(quán)訪問的受限存儲庫。

預(yù)防措施

• 禁用或監(jiān)控隱式共享連接的使用。
• 在提供對包含共享連接的環(huán)境的訪問時，遵循最小特權(quán)原則。
• 監(jiān)控?zé)o代碼/低代碼平臺的過度共享連接。
• 教導(dǎo)業(yè)務(wù)用戶了解連接共享的風(fēng)險及其與憑證共享的關(guān)系。

LCNC-SEC-03：數(shù)據(jù)泄漏和意外后果

無代碼/低代碼應(yīng)用程序通常會跨多個系統(tǒng)同步數(shù)據(jù)或觸發(fā)操作，這為數(shù)據(jù)跨越組織邊界創(chuàng)造了一條路徑，這就意味這在一個系統(tǒng)內(nèi)的操作可能會在其他系統(tǒng)中造成意想不到的后果。

攻擊場景示例

場景#1

創(chuàng)客配置了在其公司郵箱中收到的每一封新電子郵件時觸發(fā)的自動化操作，該操作會自動向創(chuàng)客的個人電子郵件賬戶發(fā)送一封新的電子郵件，并從公司郵箱中收到的原始電子郵件中復(fù)制收件人、主題和正文。由于數(shù)據(jù)是復(fù)制到單獨的郵箱而不是從公司郵箱轉(zhuǎn)發(fā)的電子郵件，因此可以自動繞過數(shù)據(jù)防泄漏（DLP）的控制。

場景#2

場景1的創(chuàng)客配置了在兩個Sharepoint網(wǎng)站之間同步更改的自動化操作，因此站點A的每一個新文件都復(fù)制到站點B。用戶2不小心將敏感文件寫入到了站點A，但不知道敏感文件會同步復(fù)制給站點B。用戶2刪除了戰(zhàn)斗A的敏感文件，然而該敏感的文件仍會存在站點B上。

預(yù)防措施

• 將平臺連接限制在批準的服務(wù)列表中。
• 將自定義連接器的創(chuàng)建限制為專職人員。
• 監(jiān)控平臺以了解組織邊界外的數(shù)據(jù)流，包括多跳路徑。

LCNC-SEC-04：身份驗證和安全通信失效

無代碼/低代碼應(yīng)用程序一般通過業(yè)務(wù)用戶設(shè)置的連接來連接到關(guān)鍵業(yè)務(wù)數(shù)據(jù)，這通常會導(dǎo)致不安全的通信。

攻擊場景示例

場景#1

創(chuàng)客創(chuàng)建了一個使用FTP連接的應(yīng)用程序，并且沒有勾選打開加密的復(fù)選框。由于應(yīng)用程序與其用戶之間的通信是加密的，因此應(yīng)用程序的用戶無法獲悉自己的數(shù)據(jù)正在未加密的情況下進行傳輸。

場景#2

創(chuàng)客使用管理員憑據(jù)來創(chuàng)建數(shù)據(jù)庫連接并構(gòu)建了一個應(yīng)用程序，且該應(yīng)用程序使用該連接向用戶顯示數(shù)據(jù)。在這種情況下，盡管創(chuàng)客的計劃是只允許用戶通過應(yīng)用程序進行只讀操作，但用戶也可以使用特權(quán)連接從數(shù)據(jù)庫中寫入或刪除記錄。

預(yù)防措施

• 在生產(chǎn)環(huán)境中，將連接的創(chuàng)建限制為專職人員。
• 監(jiān)控平臺是否存在不符合最佳做法的連接。
• 教育業(yè)務(wù)用戶了解不安全通信的風(fēng)險并且在做相關(guān)設(shè)置時需要讓安全團隊參與進來。

LCNC-SEC-05：安全配置錯誤

錯誤配置往往會導(dǎo)致匿名訪問敏感數(shù)據(jù)或操作、不受保護的公共端點、密鑰泄漏和過度共享。

攻擊場景示例

場景#1

創(chuàng)客創(chuàng)建了一個的應(yīng)用程序，該應(yīng)用程序公開了一個API端點，但該端點沒有配置為拒絕匿名訪問。攻擊者掃描低代碼/無代碼平臺的子域，找到該應(yīng)用并竊取其底層數(shù)據(jù)。

場景#2

創(chuàng)客創(chuàng)建了由webhook觸發(fā)的自動化，但未能用密鑰保護該webhook。攻擊者識別了webhook，現(xiàn)在可以隨意觸發(fā)自動化。該自動化可能是修改或刪除數(shù)據(jù)。

預(yù)防措施

• 閱讀供應(yīng)商的文檔并遵循最佳實踐指南。
• 確保配置符合行業(yè)最佳實踐。
• 監(jiān)測配置的漂移。
• 為租戶級的配置實施一個變更管理系統(tǒng)。

LCNC-SEC-06：注入處理失效

無代碼/低代碼應(yīng)用程序以多種方式接收用戶提供的數(shù)據(jù)，包括直接輸入或從各種服務(wù)中檢索用戶提供的內(nèi)容。此類數(shù)據(jù)可能會包含給應(yīng)用程序帶來風(fēng)險的惡意有效載荷。

攻擊場景示例

場景#1

創(chuàng)客設(shè)置自動化，在新RSS訂閱發(fā)布時觸發(fā)，并將該RSS訂閱存儲到 SQL 數(shù)據(jù)庫中?？刂?該RSS訂閱的攻擊者使用該流程向數(shù)據(jù)庫中注入刪除重要記錄的命令。

場景#2

創(chuàng)客創(chuàng)建了一個允許用戶填寫表單的應(yīng)用程序。該應(yīng)用程序?qū)⒈韱螖?shù)據(jù)編碼為 CSV文件并將CSV文件存儲在共享驅(qū)動器上。即使平臺為SQL注入攻擊清理了表單輸入，但并沒有針對Office宏攻擊進行清理。攻擊者利用這一點并在CSV文件中寫入一個宏。用戶打開CSV文件以分析用戶表單，然后就執(zhí)行了宏。

預(yù)防措施

• 清理用戶輸入，同時考慮應(yīng)用程序?qū)υ撦斎雸?zhí)行的操作。
• 告知業(yè)務(wù)用戶并使其了解到未經(jīng)處理的用戶輸入的會帶來的風(fēng)險，這是平臺無法自行解決的問題。

LCNC-SEC-07：易受攻擊和不可信的組件

無代碼/低代碼應(yīng)用程序在很大程度上依賴于市場上的現(xiàn)成組件、網(wǎng)絡(luò)或由開發(fā)人員構(gòu)建的自定義連接器。這些組件通常不受管理，缺乏可見性，并使應(yīng)用程序暴露在基于供應(yīng)鏈的風(fēng)險中。

攻擊場景示例

場景#1

整個組織的創(chuàng)客都使用來自公開的易受攻擊的組件。每個使用該組件的應(yīng)用程序都暴露在攻擊下。管理員可能會發(fā)現(xiàn)很難找到受漏洞組件影響的應(yīng)用程序。

場景#2

開發(fā)人員創(chuàng)建一個自定義連接器，允許創(chuàng)客連接到內(nèi)部業(yè)務(wù)API。自定義連接器在URL上傳遞身份驗證令牌并向應(yīng)用程序用戶暴露身份驗證密鑰。

預(yù)防措施

• 刪除不使用的依賴項、不必要的特性、組件、文件和文檔。
• 持續(xù)關(guān)注這些應(yīng)用程序使用的應(yīng)用程序和組件版本，并掃描該清單以查找已廢棄或易受攻擊的組件。
• 限制使用預(yù)先批準的公開組件。
• 監(jiān)控未維護的組件或未為舊版本創(chuàng)建安全補丁的組件。

LCNC-SEC-08：數(shù)據(jù)和機密處理失效

無代碼/低代碼應(yīng)用程序通常將數(shù)據(jù)或密鑰作為其“代碼”的一部分進行存儲，或者存儲在平臺提供的托管數(shù)據(jù)庫中，而這些數(shù)據(jù)必須按照法規(guī)和安全要求進行適當(dāng)?shù)拇鎯Α?/span>

攻擊場景示例

場景#1

創(chuàng)客創(chuàng)建了一個業(yè)務(wù)應(yīng)用程序，要求用戶填寫包含敏感數(shù)據(jù)的表單。應(yīng)用程序使用平臺提供的托管數(shù)據(jù)庫來存儲結(jié)果，然而由于所有其他創(chuàng)客默認使用托管數(shù)據(jù)庫進行存儲，因此其他創(chuàng)客都可以訪問到這些敏感數(shù)據(jù)。

場景#2

創(chuàng)客在創(chuàng)建的應(yīng)用程序中使用了自定義的 API，并在代碼中硬編碼了訪問該 API 的密鑰。于是，其他創(chuàng)客也就可以直接訪問到這些 API 密鑰。此外，這些API密鑰可能會泄漏到應(yīng)用程序的客戶端代碼中，從而使用戶也可以直接訪問到這些密鑰。

預(yù)防措施

• 就與數(shù)據(jù)存儲相關(guān)的合規(guī)性、隱私和安全風(fēng)險對業(yè)務(wù)用戶進行教育。
• 加強對于無代碼/低代碼供應(yīng)商提供的托管數(shù)據(jù)庫、環(huán)境變量和配置的監(jiān)控，及時發(fā)現(xiàn)不恰當(dāng)存儲的敏感數(shù)據(jù)。
• 對于涉及敏感數(shù)據(jù)處理的應(yīng)用程序，確保安全團隊參與其中。

LCNC-SEC-09：資產(chǎn)管理失效

無代碼/低代碼應(yīng)用程序易于創(chuàng)建開發(fā)，并且維護成本相對較低，這個特點使這些應(yīng)用程序在保持活動狀態(tài)的同時，組織也很容易棄用這些應(yīng)用程序。此外，內(nèi)部應(yīng)用程序可以在不解決業(yè)務(wù)連續(xù)性問題的情況下迅速普及。

攻擊場景示例

場景#1

創(chuàng)客創(chuàng)建的應(yīng)用程序成為流行的內(nèi)部工具。制作商離開組織或換了另一個角色。由于API更改，應(yīng)用程序中斷，業(yè)務(wù)中斷。IT部門根本不了解這個應(yīng)用程序，也無法幫助修復(fù)這個應(yīng)用程序。

場景#2

創(chuàng)客瀏覽平臺市場并探索應(yīng)用模板。每次單擊都會創(chuàng)建一個帶有面向外部URL的應(yīng)用程序。用戶很可能會忘記這些應(yīng)用程序，造成業(yè)務(wù)數(shù)據(jù)暴露。這種情況再乘以創(chuàng)客的數(shù)量，導(dǎo)致廢棄應(yīng)用程序資產(chǎn)數(shù)量不斷增加。

預(yù)防措施

• 維護一個包含有應(yīng)用程序、組件和用戶的全面資產(chǎn)清單。
• 刪除或禁用不使用的依賴項、不必要的特性、組件、文件以及文檔。

LCNC-SEC-10：安全記錄和監(jiān)控失效

無代碼/低代碼應(yīng)用程序通常缺乏全面的審計跟蹤，不生成日志或存在日志不足，或者對敏感日志的訪問沒有嚴格管控。

攻擊場景示例

場景#1

應(yīng)用日志已關(guān)閉。當(dāng)發(fā)生違規(guī)嘗試行為時，安全團隊無法確定誰訪問了該應(yīng)用程序以及訪問者嘗試執(zhí)行的操作。

場景#2

業(yè)務(wù)關(guān)鍵型應(yīng)用程序在發(fā)生變更后停止運行。由于發(fā)生了多個變更，每個變更都會導(dǎo)致應(yīng)用程序更新，因此很難找到哪個創(chuàng)客引入了導(dǎo)致問題的特定變更。創(chuàng)客必須手動檢查每個應(yīng)用程序版本才能找到有問題的版本。由于每個應(yīng)用程序“保存”都會轉(zhuǎn)換為更新，因此更新的數(shù)量將使手動過程的成本過高。在某些平臺上，創(chuàng)客只能查看應(yīng)用程序的當(dāng)前版本，因此創(chuàng)客將無法找到或恢復(fù)到穩(wěn)定版本。

預(yù)防措施

• 利用平臺內(nèi)置功能收集用戶訪問和平臺審核日志。
• 在適用的情況下，使用日志記錄機制檢測應(yīng)用程序，以提供額外的可見性。
• 通過配置平臺以避免記錄原始應(yīng)用程序的數(shù)據(jù)，確保日志不包含敏感數(shù)據(jù)。

– End –