Využitie nástroja ChatGPT na Secure Code Review
V dnešnej dobe je stále väčší a väčší doraz na spojenie umelej inteligencie s kybernetickou bezpečnosťou. V tomto článku sa pozrieme, či ChatGPT dokáže zefektívniť analýzu kódu.
Secure Code Review
Secure Code review (v preklade Analýza zdrojového kódu), taktiež nazývaná Static Appplication Security Testing (SAST), je jedna z metód odhaľovania bezpečnostných zraniteľností v kóde. Delí sa na manuálnu analýzu (vykonávanú človekom) a automatizovanú (vykonávanú programom).
Výhodou manuálnej analýzy kódu je nižšia šanca na false-positives a false-negatives, pričom pri dostatočnom čase je možné odhaliť väčšie množstvo zraniteľností. Veľkým mínusom je avšak potreba pokročilého chápania analyzovaného kódu a takisto jej časová náročnosť. Z tohoto dôvodu je čoraz častejšie využívanie automatizovaných nástrojov na analýzu kódu využitím programov ako napr. Checkmarx, Fortify, a iné. Je to niekoľkonásobne rýchlejšie a pre analytika jednoduchšie, ale problémom sú nepresné výsledky automatizovaných nástrojov – je veľká pravdepodobnosť false-positive a false-negative nálezov, pretože väčšina automatizovaných nástrojov nezohľadnuje kontext aplikácie a jednotlivých nálezov. Každý tento nález treba následne skontrolovať a vyvodiť závery. Najlepšie výsledky je možné získať preto kombináciou obidvoch prístupov analýzy kódu.
Najznámejšie zraniteľnosti, ktoré je možné jednoducho odhaliť pomocou Secure Code Review, sú nasledovné (poradie nie je udávajúce):
- SQL injection
- Cross-Site Scripting
- Authentication Flaws
- Cryptographic Flaws
- Buffer Overflows
- Malicious File execution
- Cross-site Request Forgery
- Sensitive information leakage
ChatGPT
ChatGPT (zo skratky Chat Generative Pre-trained Transformer) je chatbot, ktorý bol spustený v novembri 2022. Môže byť využívaný pomocou webovej stránky, ale aj rôznymi doplnkami a takisto pomocou ich zverejnenej API. Je to variant modelu GPT, ktorý sa využíva pri konverzačných robotoch a pri spracovaní prirodzeného jazyka. Aj keď základný princíp fungovania je imitovanie ľudskej konverzácie, má oveľa viac možností využitia - či už tvorba príbehov, odpovedanie na testové otázky, písanie a debugovanie kódu. Práve funkcia práce s kódom si vo svete informatiky vyslúžila najväčšiu pozornosť a začalo sa uvažovať, do akej miery sa dá ChatGPT použiť na nahradenie programátorov. Rovnako sa polemizuje nad využitím ChatGPT na penetračné testovanie aplikácií, pod ktoré spadá aj Secure Code Review - a to chceme otestovať aj my. Zostáva otázka - ako použíteľný je ChatGPT na Secure Code Review?
V tomto článku budeme využívať webovú verziu ChatGPT postavenú na modeli 3.5 (verzia 3. 8. 2023).
ASP.NET
Pre naše testovanie sme si vybrali framework ASP.NET a v ňom vytvorené zraniteľnosti. ASP.NET je framework, ktorý sa používa od roku 2002. Podľa spoločnosti w3techs, framework ASP.NET používa 6.9% stránok, ktoré poskytujú informácie o ich využívanom frameworku. Pred ním je už len PHP s 77.1%. ASP.NET je stále jeden z najviac používaných frameworkov na vytváranie webových aplikácií a je možné sa s ním často stretávať.
Zoznam najčastejších zraniteľností odhaľovaných pomocou Secure Code Review platí aj pre jazyk ASP.NET, avšak zraniteľnosť Buffer Overflow je veľmi zriedkáva, pretože sa jej snaží zabrániť samotný kompilátor.
Príklady zraniteľností
Input Validation
Veľa zraniteľností webových stránok je spojených s neexistujúcou, alebo slabou validáciou vstupných dát. Dáta by mali byť podľa best-practice validované v každom kroku aplikácie, ale málokedy sa stretávame s tým, že aj naozaj sú. Nedostatočná validácia vstupu môže viesť či už k zraniteľnosti SQL Injection, ale aj Cross-site scripting a pod.
SQL Injection
Aj keď v dnešnej dobe sa zraniteľnosť SQL Injection často v ASP.NET nevyskytuje (samotný framework poskytuje viacero spôsobov vykonávania SQL queries, ktoré sú prirodzene chránené voči injekciám, aj tak je dôležité vedieť ich detekovať. Na otestovanie sme vytvorili jednoduchý kód, ktorý obsahuje zraniteľnosť v podobe možnej SQL Injection cez email a password.
Odpoveď:
The code you've provided seems to be related to database connectivity and user authentication. However, there are several security vulnerabilities in this code that could potentially lead to security breaches or malicious attacks. Here are the main vulnerabilities:
- SQL Injection: The code concatenates user input directly into the SQL query string without proper validation or sanitization. This can make the code vulnerable to SQL injection attacks. An attacker could manipulate the input values in a way that alters the structure of the query and gain unauthorized access to the database.
Solution: Use parameterized queries or prepared statements to properly sanitize and escape user input before using it in SQL queries. This prevents SQL injection attacks. - Sensitive Data Exposure: Storing passwords in plaintext is a significant security risk. If the passwords are stored in plaintext in the database, a breach of the database could expose all user passwords, which could have serious implications for user privacy.
Solution: Hash and salt passwords before storing them in the database. When comparing passwords during login, hash and compare the provided password with the stored hashed password. - Lack of Authentication and Authorization: The code seems to be handling user authentication, but it doesn't perform any proper validation of the user's identity or authorization to access the requested resource.
Solution: Implement a proper authentication mechanism and access control. Ensure that only authenticated users can access the "index.aspx" page, and only authorized users can perform specific actions. - Hardcoded Connection String: The database connection string is hardcoded in the code. Hardcoded credentials or connection strings can be easily discovered if an attacker gains access to the source code.
Solution: Store sensitive information like connection strings in a secure configuration file, and ensure that access to this file is restricted to authorized personnel only. - No Error Handling: The code lacks proper error handling, which could lead to unexpected behavior or even application crashes if something goes wrong during database operations.
Solution: Implement appropriate error handling and logging mechanisms to capture and handle exceptions gracefully. - Lack of Input Validation: The code does not seem to perform any input validation on the email and password fields. This could lead to unexpected behavior or security vulnerabilities if invalid or malicious input is provided.
Solution: Implement input validation to ensure that user input conforms to expected formats and values.
In summary, the code is vulnerable to SQL injection, exposes sensitive data, lacks proper authentication and authorization, uses hardcoded credentials, lacks error handling, and lacks input validation. It's crucial to address these vulnerabilities to ensure the security and integrity of your application.
Táto odpoveď je viacmenej správna - kód obsahuje zraniteľnosť SQL Injection, heslo je v plain texte. Avšak máme tu prvý false positive - 4. bod. ChatGPT usúdil, že riadok
string strcon = ConfigurationManager.ConnectionStrings["users"].ConnectionString;
značí hardcoded string, pričom to ale nie je pravda - z poskytnutého kódu sa nedá usúdiť, či samotný connectionString vo web.configu je v plaintexte. Čo ak ale kód upravíme tak, aby obsahoval aj overenie vstupu od používateľa? Vstup upravíme nasledovne (použijeme blacklisting, čo nie je odporúčaný spôsob):
Odpoveď:
The provided code contains several security vulnerabilities that could potentially be exploited by attackers. Let's go through them one by one:
- Lack of Input Sanitization: The code directly uses user inputs (password andemail) to construct an SQL query without any form of input sanitization or validation. This makes the code susceptible to SQL injection attacks.
- Blacklisting Approach: The code attempts to prevent attacks by blacklisting certain strings (<SCRIPT>,--,'). However, this approach is ineffective for several reasons. Attackers can easily bypass these filters by using variations of these strings, different encodings, or even using whitespace to obfuscate their inputs.
- Case-Insensitive Checks: The code converts user inputs to uppercase before checking for blacklisted strings. While this might make it harder for attackers to simply use lowercase variations of the blacklisted strings, it's not a foolproof way to prevent attacks.
- Concatenation of SQL Query: The SQL query is constructed by concatenating strings, which is a bad practice and opens the code to SQL injection vulnerabilities. An attacker could manipulate theemail andpassword values to inject malicious SQL code into the query.
- Hardcoded Password and Email Fields: The code assumes thatLogin1.password andLogin1.email are available and contain the user-provided values. If these fields aren't properly validated or sanitized, an attacker could exploit this vulnerability.
- No Use of Parameterized Queries: The code does not utilize parameterized queries, which are the recommended approach for preventing SQL injection. Parameterized queries handle input sanitization automatically and are much more secure than manually constructing queries.
- Lack of Error Handling: The code lacks proper error handling, making it difficult to identify issues during database interactions or other operations. This lack of error handling can potentially expose sensitive information to attackers.
Tento výstup je už zaujívamejší a vidíme hneď viacero problémov:
- ChatGPT hovorí o tom, že chýba validáciu vstupu a odôvodňuje to tým, že vstupy password a email sú použité priamo - neberie do úvahy to, že vstup prechádzke cez blacklist (čo je veľmi neefektívny a neodporúčaný spôsob validácie, ale stále je) a poukazuje na existujúcu zraniteľnosť SQL Injection, čo je v tomto prípade false positive
- Správne.
- Táto odrážka vlastne nič nehovorí.
- Pravda, tento spôsob tvorby SQL dopytov je bad practice, ale v tomto prípade nevedie k SQL Injection.
- False positive
- Znova odrážka o queries - SQL Injection už vo svojej odpovedi spomenul trikrát a áno, parametrizované dopyty sú odporúčané, ale v tomto prípade je stále SQL Injection false positive
- Správne.
ChatGPT nám teda povedal, že nevalidujeme vstup, potom že vstup validujeme ale zle, a že máme zraniteľnosť SQL Injection. Na jednu stranu je dobré upozorniť na best practice, avšak v tomto prípade aj keď je kód zložený "najhorším" možným spôsobom, sám o sebe zraniteľný nie je. Ďalším problémom je, že ChatGPT nevie o celom kontexte aplikácie - vo web.configu môže byť príkaz <validateRequest="true"/> , ktorý v prípade nepovoleného vstupu vyhodí error a tým zamedzí viacero typov zraniteľností, alebo môže existovať validácia na iných miestach aplikácie.
Sensitive information leakage
Jedným z častých problémov webových stránok je zdieľanie citlivých údajov s obyčajnými používateľmi. Jedným zo spôsobov ako sa k citlivým dátam dostať je vyvolanie chybových stavov a tým získanie pohľadu na interné fungovanie aplikácie.
Na otestovanie sme použili nasledujúce 3 časti kódu zaradom:
Odpoveď:
The provided code still has security vulnerabilities that should be addressed:
- Information Disclosure - Exception Details: While the code uses ex.ToString() instead of directly exposing the stack trace, it's important to note that the ToString() method of an Exception object can still contain sensitive information, including the exception message, stack trace, and inner exception details. Displaying this information to end-users can expose implementation details and aid attackers in identifying potential vulnerabilities.
- Insufficient Error Handling: Although the code captures exceptions and displays their details, it lacks proper error handling mechanisms. It doesn't offer a robust way to log or manage the errors effectively, which can lead to incomplete error resolution and difficulties in identifying and addressing issues.
- Premature Error State Clearing: Clearing the error state using Context.ClearError() right after displaying the error message could still potentially interfere with other error-handling mechanisms and result in incomplete error resolution.
To improve security and error handling:
- Avoid displaying sensitive exception details directly to end-users. Consider providing a user-friendly error message to users while logging the detailed exception information securely for debugging purposes.
- Implement comprehensive error handling mechanisms, including logging errors securely, notifying administrators, and providing a user-friendly experience.
- Clear the error state after you've completed necessary error handling actions, ensuring that doing so won't interfere with other error-handling processes.
ChatGPT v tomto prípade odpovedal správne, avšak tieto zrateniľnosti sú veľmi jednoduché na odhalenie.
Únik údajov môže byť takisto spôsobený zlým nastavením configu:
Odpoveď:
Based on the provided code snippet, here are the potential security vulnerabilities and concerns that can be identified:
- Detailed Error Messages in Production: ThecustomErrors configuration sets themode attribute to "Off," which means detailed error messages will be displayed to users in a production environment when a server error occurs. This can expose sensitive information about the application's internals and potentially aid attackers in finding vulnerabilities.
Recommendation: Set themode attribute to "On" or "RemoteOnly" in a production environment to display generic error messages to users while logging detailed error information on the server side. - Potential Information Disclosure: If the "InternalError.htm" page referenced in thecustomErrors section contains sensitive information or stack traces, it could potentially be accessed by attackers. They might use this information to gain insights into the application's architecture and attempt targeted attacks.
Recommendation: Ensure that the error pages provided do not contain sensitive information and only reveal what's necessary for users. - Lack of Input Validation: Although the provided code snippet does not show direct user input, if the filenames ("GenericError.htm" and "InternalError.htm") are determined dynamically (e.g., based on user input), proper input validation and sanitation are crucial to prevent path traversal or other injection attacks.
Recommendation: If these filenames are determined dynamically, validate and sanitize the input to prevent malicious manipulation. - Inadequate Exception Handling: The<runtime> section setting<ThrowUnobservedTaskExceptions enabled="false"/> could potentially suppress unobserved task exceptions. This might lead to situations where exceptions are not properly handled and logged, potentially affecting application stability and security.
Recommendation: Ensure that exceptions are properly handled and logged in the application to aid in debugging and identifying potential security issues. - XDT Transformation Security: If the XDT transformations are not managed securely, unauthorized users might modify the transformations to inject malicious settings into the application's configuration.
Recommendation: Implement proper access controls and validation for XDT transformations to prevent unauthorized modifications.
It's important to note that the identified concerns might vary depending on the broader context of your application and how this configuration file is being used. Regular security reviews, code audits, and adherence to security best practices are essential to maintain the security of your application.
ChatGPT správne odhalil potrebu mať customErrors nastavená na On alebo RemoteOnly, avšak v prípade <ThrowUnobservedTaskExceptions enabled="false"/> to nebral ako možnú zraniteľnosť, iba vychádzal z toho že je to nastavené na false a že to "môže niečo spôsobiť" , čo pri secure code review nestačí.
Cryptographic Flaws
Aj keď veľmi zriedkavo vyskytujúce, pretože použitím funkcií frameworku sa tejto zraniteľnosti dá veľmi jednoducho vyhnúť, stále je potrebné vedieť tento typ zraniteľnosti detekovať. Ako príklad sme vytvorili kód, kde je až 6 kryptografických zraniteľností a následne ho dali skontrolovať pomocou ChatGPT:
Odpoveď:
The code you've provided seems to be setting up a symmetric encryption algorithm using the Data Encryption Standard (DES) cipher. While the code itself doesn't immediately indicate security vulnerabilities, there are several security concerns and potential vulnerabilities associated with this code:
- Use of Weak Cipher (DES): DES is considered a weak encryption algorithm by modern security standards. It has been deprecated due to vulnerabilities such as small key size, susceptibility to brute force attacks, and advances in cryptanalysis techniques. It's highly recommended to use stronger encryption algorithms like AES (Advanced Encryption Standard) instead.
- Static Key: The encryption key ("hashpassword") is hard-coded into the source code. This makes the application vulnerable to key exposure if an attacker gains access to the source code or the compiled application. It's important to securely manage encryption keys and avoid hard-coding them.
- Use of ECB Mode: The code specifies the Electronic Codebook (ECB) mode for encryption. ECB mode is insecure for many use cases because it doesn't provide semantic security. Identical plaintext blocks are encrypted into identical ciphertext blocks, potentially leaking patterns in the data.
- Weak Padding Scheme: The code uses PaddingMode.Zeros for padding. This padding mode can leak information about the original data, especially if the data ends with zero bytes. Padding schemes like PKCS7 or ISO/IEC 7816-4 are more secure and widely used.
- Inconsistent Key and Block Size Settings: The code sets both theenc.KeySize andenc.BlockSize properties to 32. This is inconsistent with DES, which typically uses a key size of 56 bits and a block size of 64 bits. Inconsistent settings could lead to unexpected behavior or insecure encryption.
- Lack of Initialization Vector (IV): The code snippet doesn't include the use of an initialization vector (IV). An IV is essential for enhancing security, especially when using encryption modes other than ECB.
- Missing Error Handling: The code doesn't show error handling or exception management. In a real-world application, robust error handling is crucial to prevent crashes and unintended behaviors.
- Deprecated API Usage: The code uses deprecated methods likeSymmetricAlgorithm.Create("DES"). It's recommended to use modern API calls and adhere to current best practices.
To address these vulnerabilities, consider the following actions:
- Use a stronger encryption algorithm like AES.
- Generate and manage encryption keys securely, preferably using a key management system.
- Choose an appropriate encryption mode (e.g., CBC, GCM) and use a secure padding scheme.
- Implement proper error handling and exception management.
- Stay up-to-date with security best practices and avoid using deprecated methods or outdated cryptographic techniques.
Aj v tomto prípade odhalil ChatGPT všetky kryptografické nedostatky.
Malicious File execution
Táto časť je jedna z najzaujímavejších, pretože zahŕňa aj nahratie súborov - v tomto prípade žiadna validácia súborov, s tým spojený Remote Code Execution, a iné:
Odpoveď:
The code you've provided appears to be an ASP.NET web application code snippet for handling file uploads. While this code seems simple and straightforward, there are several security vulnerabilities and best practice issues that need to be addressed:
- Missing Authentication and Authorization: The code does not perform any authentication or authorization checks. It allows anyone, including unauthenticated users, to upload files to the server. This can lead to unauthorized access to sensitive functionality or resources.
Implement authentication and authorization checks to ensure that only authorized users can upload files. You should also consider implementing role-based access control to restrict access based on user roles. - Lack of Input Validation: The code does not validate user input or sanitize file names. This can lead to various security issues, including cross-site scripting (XSS) attacks if an attacker uploads a file with a malicious filename.
You should sanitize and validate all user inputs, including file names, to prevent potential security vulnerabilities. - Missing Error Handling: The code lacks proper error handling, which means that if an error occurs during the file upload process, it may expose sensitive server information to the user or disrupt the application's functionality. You should implement error handling to provide meaningful error messages to users and log detailed error information securely.
- Lack of Size Limitations: There is no check for the size of the uploaded file. Allowing users to upload large files can consume server resources and lead to denial-of-service (DoS) attacks. You should enforce maximum file size limits and validate the file size before saving it.
- Lack of File Type Validation: The code does not validate the type of file being uploaded. Without proper validation, an attacker could upload malicious files, such as executable files, scripts, or other dangerous content, which could lead to various security issues, including code execution vulnerabilities.
To mitigate this, you should check the file's content type and ensure that it matches an allowed set of file types (e.g., only allowing certain image formats or PDF files). - Insecure File Storage: The code directly saves the uploaded file to the server's "upload" directory using the original file name. This can be exploited in several ways:
- Directory traversal attacks: An attacker might manipulate the file name to access other directories on the server, potentially exposing sensitive files.
- Overwriting files: If a file with the same name already exists, it will be overwritten without warning
To address this, you should generate a unique filename for each uploaded file and store metadata about the uploaded file, including the original filename, in a database.
To address these security vulnerabilities, you should thoroughly validate, sanitize, and secure the file upload process, including implementing proper file type checks, secure file naming, access control, error handling, and size limitations. Additionally, consider using a well-established file upload library or framework that has built-in security features to simplify these tasks.
Aj keď na prvý pohľad vyzerá tento výstup veľmi dobre, je celkom sklamaním. Pravda, znova ChatGPT detekoval neexistujúcu validáciu, dokonca v 2. bode spomenul aj directory traversal a možné prepisovanie súborov, ale chýba tu zraniteľnosť Remote Code Execution. Áno, človek si môže znova povedať, že predsa danej zraniteľnosti môže byť zabránené inde - napr. pri samotnej GET požiadavke na daný súbor, avšak to isté môžeme povedať o nastavení maximálnej veľkosti (ktorá sa dá nastavovať a aj nastavuje v IIS). Problémom nie je to, že spomenul limitáciu veľkosti súborov, ale jeho nekonzistentnosť. Remote Code Execution je oveľa závažnejší problém ako samotné nelimitovanie veľkosti súboru v kóde a teda by sme očakávali, že bude spomenutý.
Iné zraniteľnosti
Veľké množstvo zrateniteľností je spôsobené nesprávnou konfiguráciou vo web.config. Vytvorili sme príkladový konfiguračný súbor s množstvom nesprávných nastavení (viac než 10).
Odpoveď:
The provided web.config file contains several misconfigurations that could potentially lead to security vulnerabilities. Here are some of the key issues:
- Request Validation Disabled (validateRequest="false"): Multiple instances of<pages validateRequest="false" /> suggest that request validation is disabled globally. Request validation helps protect against Cross-Site Scripting (XSS) attacks by ensuring that user inputs are properly sanitized before being displayed. Disabling request validation could expose the application to XSS vulnerabilities.
- Custom Errors Revealing Sensitive Information (<customErrors mode="Off" />): ThecustomErrors section is set toOff, which means that detailed error messages might be displayed to users in the event of an error. This can expose sensitive information about the application's structure and logic, potentially aiding attackers in their efforts.
- Debug Mode Enabled (debug="true"): Debug mode is enabled for both compilation and runtime, which could expose sensitive debugging information to potential attackers. Debugging symbols and trace information could be leveraged by attackers to identify vulnerabilities in the application.
- Weak Authentication Configuration (<forms>): The<forms> section of authentication is using thepasswordFormat="Clear". This means that user passwords are stored in clear text, which is highly insecure. Passwords should be hashed and salted to enhance security.
- Session Cookie Security (<httpCookies> and<machineKey>): The<httpCookies> section and<machineKey> sections do not enforce security measures such ashttpOnlyCookies,secure, or strong encryption methods. Without these settings, session cookies are more vulnerable to attacks like session hijacking and information leakage.
- Outdated and Vulnerable Dependencies (<dependentAssembly>): The<dependentAssembly> elements in the<assemblyBinding> section specify binding redirects for certain assemblies. This could potentially lead to the use of outdated and vulnerable versions of these assemblies, exposing the application to security risks.
- Obsolete CodeDom Compiler Configuration (<system.codedom>): The<system.codedom> section specifies the configuration for compilers. It references an older version of theDotNetCompilerPlatform, which could contain security vulnerabilities that have been patched in later versions.
- Disclosure of Entity Framework Configuration (<entityFramework>): The configuration for Entity Framework providers is exposed in the<entityFramework> section. While not necessarily a security vulnerability, disclosing this information could provide attackers with insights into the application's database structure.
It's important to note that security vulnerabilities depend on the specific context and usage of the application. Regularly reviewing and updating theweb.config file, following security best practices, and staying informed about the latest security updates for libraries and frameworks used in the application can help mitigate these potential vulnerabilities.
Aj keď ChatGPT zachytil viacero zraniteľností, nezachytil napríklad nasledovné:
- zapnutý trace
- v 4. bode síce spomína, že je využívaný clear text pre ukladanie hesiel, avšak daný príkaz obsahuje oveľa viac problémov - cookies sú prenášané pomocou URL adresy aj pomocou HTTP, je nastavený vysoký timeout, nie je zapnutá žiadna ochrana a pri každom requeste sa obnovuje jej trvanie. Takisto nemá problém s hardcoded heslom.
- v 5. bode hovorí o machineKey, ale nespomína využitie zastaralých metód MD5 a DES
- requireSSL je vypnuté vo viacerých častiach, avšak ChatGPT ho nespomína ani raz
Problémy využitia ChatGPT na analýzu kódu
Po prečítaní predchádzajúcej kapitoly, kde ChatGPT detekoval veľkú väčšinu zraniteľných miest v častiach kódu, ktoré sme mu poskytli, je jednoduché nadobudnúť dojem, že ChatGPT dokáže nahradiť iné nástroje pri analýze kódu. Vzniká tu avšak viacero problémov.
- maximálna dĺžka vstupu a výstupu je 4096 tokenov
V našom prípade sme zadávali len jendoduché časti kódu a teda tento limit sme nedosiahli. V reálnom svete môže mať kód avšak niekoľko diesatok tisíc riadkov a v tomto prípade dosiahneme veľmi rýchlo nastavený limit, čo znemožní správne detekovanie zraniteľností.
- zdieľanie kódu s 3. stranou
Je veľmi lákavé skopírovať kód a nechať si ho skontrolovať pomocou ChatGPT, ale je potrebné si uvedomiť, že v tomto prípade zdieľame svoj kód s 3. stranou. Kód často obsahuje citlivé informácie a často predstavuje cenné a dokonca pre podnikanie dôležité duševné vlastníctvo. Podlieha prísnym licenčným podmienkam, ktoré obmedzujú jeho zverejnenie. Odoslanie kódu tretej strane na analýzu môže predstavovať zmluvný problém, takže neprichádza do úvahy, aj keby bol efektívny.
- výskyt false positive nálezov
Ako sme na niektorých prípadoch ukázali, je jednoduché dosiahnuť false positive nálezy, keďže ChatGPT nepozná kontext celej aplikácie. Obzvlášť je to problémové vo frameworkoch ako je ASP.NET, kde validáciu vstupu a iné rôzne nastavenia sa nemusia vykonávať priamo v kóde ale sú zabudované do frameworku, respektíve nastavujú sa na strane IIS.
Po prezerení všetkých problémov môžeme usúdiť, že stráca zmysel používať ChatGPT na Secure Code Review. Aby bol užitočný, potrebovali by sme ho využívať ako automatizovaný nástroj, do ktorého hodíme celý kód a on nám povie zraniteľnosti (podobne ako iné automatizované nástroje). Na toto však ChatGPT nie je použíteľný z dôvodov uvedených vyššie. Zostáva nám teda využitie na analýzu malých častí kódu - avšak aj tu narážame na problém zdieľania kódu s 3. stranou. Možné použitie vidíme avšak v jeho integrovaní do pipeline vývoja - napr. pri každom pull requeste by sa daný kód dal skontrolovať pomocou ChatGPT - mohol by pomôcť odhaliť najzákladnejšie chyby (avšak ani táto integrácia sa nevyhne zdieľaniu kódu s 3. stranou).
Záver
V tomto článku sme chceli poukázať na možné použitie nástroja ChatGPT na secure code review. Zistili, sme že aj keď vie nájsť všetky základné zraniteľnosti, ktoré by sa mohli v dnešných kódoch vyskytnúť, nevie sa vyvarovať false positive nálezom a má taktiež iné problémy, ktoré znižujú možnosti jeho využitia. Vzhľadom na našie zistenia myslíme, že momentálne existujú lepšie riešenia ako ChatGPT na Secure Code Review.