WO2021085983A1 - 소스 코드에서 취약성을 탐지하기 위한 방법, 디바이스, 및 컴퓨터 판독가능 매체 - Google Patents

소스 코드에서 취약성을 탐지하기 위한 방법, 디바이스, 및 컴퓨터 판독가능 매체 Download PDF

Info

Publication number
WO2021085983A1
WO2021085983A1 PCT/KR2020/014747 KR2020014747W WO2021085983A1 WO 2021085983 A1 WO2021085983 A1 WO 2021085983A1 KR 2020014747 W KR2020014747 W KR 2020014747W WO 2021085983 A1 WO2021085983 A1 WO 2021085983A1
Authority
WO
WIPO (PCT)
Prior art keywords
lines
line
source code
detecting
value assignment
Prior art date
Application number
PCT/KR2020/014747
Other languages
English (en)
French (fr)
Inventor
최신형
Original Assignee
삼성전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Publication of WO2021085983A1 publication Critical patent/WO2021085983A1/ko
Priority to US17/661,155 priority Critical patent/US20220253533A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G06F21/563—Static detection by source code analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/034—Test or assess a computer or a system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/42—Syntactic analysis
    • G06F8/427—Parsing

Definitions

  • the present disclosure relates to detecting vulnerabilities in source code, and specifically, to detecting vulnerabilities due to information hard coded in the source code.
  • Source code is text written in a human-readable programming language and is an element that makes up a program.
  • a computer can execute a program by reading the source code through a compiler.
  • the source code includes data on the structure or algorithm of the program
  • leakage of the source code may be disadvantageous to the program developer.
  • the number of projects that develop programs in an open source method of releasing source codes is increasing.
  • Embodiments of the present disclosure are to provide a technique for detecting vulnerabilities in source code.
  • a method comprising: obtaining a source code; Parsing the source code to extract value assignment lines; Detecting first lines of the value assignment lines based on keywords; Detecting second lines of the value assignment lines based on credential patterns; Determining third lines of the first lines based on the number of lines that satisfy a predetermined condition among the first lines; And outputting vulnerabilities of the second lines and the third lines.
  • a method including a can be provided.
  • a method of obtaining the source code based on access information transmitted from a user through a web page may be provided.
  • the method may further include an operation of obtaining project files, and a method in which the source code is included in a code file among the project files may be provided.
  • the method of obtaining the source code may include an operation of excluding a media file from among the project files.
  • a method of extracting the value assignment lines may be provided by tokenizing the source code into a key, a separator, and a value.
  • the keywords include a first keyword and a second keyword
  • the first lines include a line related to the first keyword
  • the operation of detecting the first lines is related to the second keyword and a predetermined word
  • a method including an operation of excluding a line including a may be provided.
  • a method may be provided in which the predetermined word is a word registered in a dictionary.
  • the detecting of the first lines may include an operation of excluding a line that is encrypted while being associated with at least one of the keywords among the value assignment lines.
  • the detecting of the second lines may include an operation of excluding a line that satisfies a predetermined entropy condition while matching at least one of the credential patterns.
  • a method including the degree of similarity may be provided for the predetermined condition.
  • the determining of the third lines may include an operation of excluding the lines based on the number of the first lines satisfying the predetermined condition.
  • a method of excluding the lines may be provided.
  • a method in which the predetermined number is 10 may be provided.
  • the method includes an operation of identifying a file path and file name of files including the second lines or the third lines, and the vulnerability of the second lines and the third lines is determined by the file path and A method of outputting based on the file name may be provided.
  • a line including a predetermined word in a file path or a file name may have fewer vulnerabilities than a line in which the predetermined word is not included in the file path or file name.
  • the method may include an operation of determining connectivity to service providers based on the second lines, and a method in which the vulnerability of the second lines is output based on the connectivity may be provided. .
  • a method of providing the vulnerability to a user through a web page may be provided.
  • a device comprising: a computer-readable medium storing instructions; And a processor, wherein the processor executes the instructions: obtaining a source code; Parsing the source code to extract value assignment lines; Detecting first lines of the value assignment lines based on keywords; Detecting second lines of the value assignment lines based on credential patterns; Determining third lines of the first lines based on the number of lines that satisfy a predetermined condition among the first lines; And outputting vulnerabilities of the second lines and the third lines.
  • a device configured to perform an operation may be provided.
  • a computer-readable medium storing instructions, the instructions being executed by a processor, causing the processor to obtain a source code; Parsing the source code to extract value assignment lines; Detecting first lines of the value assignment lines based on keywords; Detecting second lines of the value assignment lines based on credential patterns; Determining third lines of the first lines based on the number of lines that satisfy a predetermined condition among the first lines; And outputting vulnerabilities of the second lines and the third lines.
  • a computer-readable medium may be provided to perform the operation.
  • FIG. 1 is a block diagram of a device according to an embodiment.
  • FIG. 2 is a flow chart of a method according to an embodiment.
  • FIG. 3 is a block diagram of a parser according to an embodiment.
  • FIG. 4 is a block diagram of a weak line detection unit according to an exemplary embodiment.
  • FIG. 5 is a flowchart of a method of detecting a weak line based on a keyword according to an exemplary embodiment.
  • FIG. 6 is a flowchart of a method of detecting a weak line based on a credential pattern according to an exemplary embodiment.
  • FIG. 7 is a block diagram of a vulnerability output unit according to an exemplary embodiment.
  • FIG. 8 is a flowchart of a method for classifying lines based on similarity according to an embodiment.
  • FIG. 9 is a flowchart of a method for classifying a level of vulnerability according to an exemplary embodiment.
  • FIG. 10 is a block diagram of an automatic vulnerability analysis system according to an embodiment.
  • FIG. 11 is a diagram for describing a method of operating a server according to an exemplary embodiment.
  • FIG. 12 shows an exemplary source code of a configuration file of a credential scanner.
  • ... unit and “module” described in the specification mean a unit that processes at least one function or operation, which may be implemented as hardware or software or a combination of hardware and software. .
  • first, second, and the like are used to describe various elements, it is a matter of course that these elements are not limited by these terms. These terms are only used to distinguish one component from another component. Therefore, it goes without saying that the "first component” mentioned below may be a “second component” within the technical idea of the embodiment.
  • At least one modifies the entire list of elements and does not individually modify the elements of the list.
  • at least one of A, B, and C means only A, only B, only C, all A and B, all B and C, all A and C, all A and B and C, or a combination thereof. Points to.
  • electronic devices include smartphones, tablets, mobile phones, personal digital assistants (PDAs), media players, portable multimedia players (PMPs), e-book terminals, digital broadcasting terminals, personal computers (PCs), laptop computers, and microcomputers. It may be a server, a global positioning system (GPS) device, a navigation device, a kiosk, an MP3 player, a smart TV, a digital camera, and other mobile devices, but is not limited thereto.
  • PDAs personal digital assistants
  • PMPs portable multimedia players
  • e-book terminals digital broadcasting terminals
  • PCs personal computers
  • microcomputers It may be a server, a global positioning system (GPS) device, a navigation device, a kiosk, an MP3 player, a smart TV, a digital camera, and other mobile devices, but is not limited thereto.
  • GPS global positioning system
  • a weak line may be detected in the source code, and a vulnerability of the detected line may be output. Therefore, by examining the vulnerabilities of the source code before the source code of the open source program is disclosed, an accident due to leakage of confidential information can be prevented.
  • the weak line refers to a line that is determined to include, or is determined to include, confidential information, for example, authentication information required to access an API (application programming interface) or specific information in the source code. If a vulnerable line is disclosed along with the source code, confidential information contained in the vulnerable line may be exploited.
  • confidential information for example, authentication information required to access an API (application programming interface) or specific information in the source code.
  • the vulnerability of a line in this disclosure indicates that the line contains or has been determined to contain confidential information.
  • Vulnerability may refer to the degree of vulnerability, and the degree of vulnerability may be determined based on the importance of confidential information included in the corresponding line, the existence of lines similar to the corresponding line, the number of similar lines, and the like.
  • FIG. 1 is a block diagram of a device according to an embodiment.
  • a device 100 may include a parsing unit 110, a weak line detection unit 120, and a vulnerability output unit 130.
  • the parsing unit 110, the weak line detection unit 120, and the vulnerability output unit 130 may be implemented as a module that performs a corresponding function, for example, a software module, but is not limited thereto. It may be implemented or may be implemented as a combination of a hardware module and a software module.
  • the device 100 may include more or fewer units than the number of units described above.
  • a specific operation performed by the device 100 is necessarily performed by a specific unit. It should not be understood.
  • an operation depicted as being performed in a specific unit of the device 100 may be performed in another unit, and an operation depicted as being performed in one unit of the device 100 is a plurality of units.
  • An operation described as being performed by an interactive processing between a plurality of units of the device 100 may be performed by a single unit.
  • an operation depicted as being performed by the device 100 may be performed by another device or may be performed with the help of another device.
  • Device 100 may include a memory and a processor.
  • the software modules of the device 100 for example, program modules, may be stored in memory as a set of instructions, and the instructions may be executed by a processor so that corresponding functions may be performed.
  • parsed Information may be parsed through the parsing unit 110.
  • source code files input to the parser 110 may be parsed.
  • a weak line may be detected in the source code.
  • a weak line refers to a line containing confidential information, for example, authentication information required to access APIs or specific information.
  • the weak line detection unit 120 may detect a line including text related to a password, a key, a credential, a token, or the like in the source code.
  • the vulnerable line may point to only text corresponding to confidential information in the source code or may point to a line containing the text.
  • lines may include not only lines of code, but also comment lines.
  • Lines can be divided into physical lines as well as logical lines. Each physical line can be divided by a line break or not, and each logical line can be divided by a command.
  • a weak line may be detected in the source code based on a keyword or a credential pattern.
  • the vulnerability of the detected weak line may be output through the vulnerability output unit 130.
  • the vulnerability of a line indicates that the line contains, or has been determined to contain, confidential information.
  • lines that are not actually vulnerable among the detected weak lines may be classified through the vulnerability output unit 130, or lines may be classified according to a degree of vulnerability.
  • a method of detecting a vulnerability in a source code according to an embodiment of the present disclosure will be described further with reference to FIG. 2.
  • FIG. 2 is a flow chart of a method according to an embodiment.
  • the device 100 may obtain the source code.
  • the source code may be obtained from the file through the parsing unit 110.
  • a plurality of source code sets may be obtained from a plurality of files. A method of obtaining the source code will be described later with reference to FIG. 3.
  • the device 100 may extract value assignment lines from the source code.
  • the value assignment lines indicate lines to which a value is assigned in the source code, and may be extracted by parsing the source code through the parsing unit 110. A method of extracting the value assignment lines from the source code will be described later with reference to FIG. 3.
  • the device 100 may detect first lines among the value assignment lines.
  • the first lines may be detected based on keywords through the weak line detection unit 120. A method of detecting the first line will be described later with reference to FIG. 5.
  • the device 100 may detect second lines of the value assignment lines.
  • the second lines may be detected based on credential patterns through the weak line detection unit 120. A method of detecting the second line will be described later with reference to FIG. 6.
  • the device 100 may determine third lines of the first lines.
  • third lines may be determined based on lines that satisfy a predetermined condition among the first lines. A method of determining third lines among the first lines will be described later with reference to FIG. 8.
  • the device 100 may output vulnerabilities of the detected lines.
  • the vulnerability of the first lines and the second lines may be output through the vulnerability output unit 130.
  • the determined third lines among the first lines and the vulnerabilities of the second lines may be output through the vulnerability output unit 130.
  • a method of classifying the vulnerability levels of lines will be described later with reference to FIG. 9.
  • the credential scanner may refer to a program that detects weak lines in source code.
  • each unit of the device 100 may each include sub-units. have.
  • the subunits of each unit may be more or less than those depicted in this disclosure. Since subunits are individually named in each unit in order to distinguish and describe operations performed by each unit, it should not be understood that a specific operation performed by each unit is necessarily performed by a specific subunit.
  • an operation depicted as being performed on a particular sub-unit may be performed in another sub-unit, an operation depicted as being performed in one sub-unit may be performed in a plurality of sub-units, An operation described as being performed by interactive processing between a plurality of sub-units may be performed by one sub-unit.
  • an operation depicted as being performed in a particular unit may be performed in another unit, or may be performed with the help of another unit.
  • Units and subunits may have a hierarchical relationship with each other, but since subunits are individually named in each unit to distinguish and describe the operations performed in each unit, the unit and subunits are hierarchical to each other. You may not be in a relationship.
  • FIG. 3 is a block diagram of a parser according to an embodiment.
  • the parsing unit 110 of the device 100 may include a file selection unit 112, a file type determination unit 114, and a value assignment line extraction unit 116.
  • the device 100 may extract the value assignment lines L1 by obtaining and parsing the source code files through the parser 110.
  • the source code can be obtained from a file, and a plurality of source code sets can be obtained from a set of project files.
  • the source code may be obtained based on access information transmitted from a user through a web page.
  • the access information may indicate the location of the project files, and the device 100 may access the project files through the access information.
  • Project files may be stored in a repository outside the device 100.
  • Files to be inspected among project files may be selected or excluded through the file selection unit 112. That is, a scan may be performed on some selected files, and a scan may not be performed on excluded files. Therefore, vulnerabilities of project files can be efficiently detected.
  • files that are likely not to include a weak line for example, media files, may be excluded from the scan.
  • the extension of the file to be excluded may be set.
  • the file type of the file to be checked may be determined through the file type determination unit 114.
  • the file type may be determined based on an extension or a file signature of the file.
  • the file can be parsed using different parsers depending on the determined file type. In this case, whether or not the file can be parsed may be determined, and only files that can be parsed may be parsed.
  • the source code may be parsed through the value assignment line extracting unit 116 to extract value assignment lines L1 from the source code.
  • the value assignment lines L1 can be extracted from the source code. That is, the value assignment line includes a key, a separator, and a value, and a key and a value may be separated by a separator.
  • the separator can be different depending on the file type of the file being parsed.
  • a weak line may be detected among the value allocation lines L1 extracted from the source code, which will be described with reference to FIG. 4.
  • FIG. 4 is a block diagram of a weak line detection unit according to an exemplary embodiment.
  • the weak line detection unit 120 of the device 100 may include a first line detection unit 121 and a second line detection unit 122.
  • the weak lines L2 among the value allocation lines L1 of the source code may be detected through the weak line detection unit 120 of the device 100.
  • the weak lines L2 may be detected based on a keyword or pattern.
  • the weak line L2 detected based on a keyword may be referred to as a first line
  • the weak line L2 detected based on a pattern may be referred to as a second line.
  • the first line detection unit 121 may detect a line including a specific keyword in order to detect a weak line L2 that is not standardized or difficult to be standardized.
  • the second line detector 122 may detect a line having a specific pattern in order to detect a relatively standardized weak line L2.
  • the first line detection unit 121 may include a keyword-based extraction unit 121a, a whitelist verification unit 121b, and a dictionary verification unit 121c, and the first line detection unit 121 A method of detecting the first line based on the keyword through) will be described with further reference to FIG. 5.
  • FIG. 5 is a flowchart of a method of detecting a weak line based on a keyword according to an exemplary embodiment.
  • the first line detector 121 may extract a line based on a keyword from among the value assignment lines L1 extracted from the source code.
  • the keywords may be keywords related to passwords, keys, credentials, tokens, and the like.
  • keywords may be “token”, “credential”, “api”, “key”, “credentials”, and “secret”, It is not limited, and the keyword may further include “password”, "pw”, and "pass”, as described in "dicKeywords" of the 7th line of FIG. 12.
  • lines including the keyword among the value assignment lines L1 may be extracted through the keyword-based extraction unit 121a.
  • the following regular expression may be used, for example:
  • the line containing the keyword is highly likely to be a line related to authentication information required to access API or specific information, that is, a line containing confidential information, if the line is disclosed while being included in the source code, It can be exploited as a vulnerability point. Therefore, by detecting such a weak line L2 before the source code is disclosed, an accident due to leakage of confidential information can be prevented.
  • the first line detector 121 may determine whether the extracted line corresponds to a white list.
  • all lines including the keyword may not be the weak line L2. Therefore, by filtering out the line corresponding to the white list through the white list verification unit 121b, non-vulnerable lines, that is, lines that do not contain confidential information or are determined to be unfairly used are excluded. I can.
  • the encrypted line may be included in the white list. Whether a line is encrypted may be determined based on whether the line contains a regular expression associated with encryption.
  • the encrypted line may refer to a line in which not only confidential information but also the entire line is encrypted. Even if an encrypted line is leaked, it is impossible or difficult to unfairly use it as a vulnerability, and thus, by excluding the encrypted line from the first line list, the FP (false positive) rate of the detected weak lines L2 may be reduced.
  • the first line detection unit 121 may determine whether the extracted line is a line requiring dictionary verification, and perform dictionary verification on the corresponding line. According to an embodiment, the determination of whether to correspond to the white list and the dictionary verification may be performed in a different order or may be performed in parallel.
  • the first line detector 121 may filter out a line further including a predetermined word from among the extracted lines through dictionary verification. That is, through dictionary verification, it may be determined whether the extracted line further includes a word frequently used in the source code and registered in advance.
  • non-fragile lines that is, lines determined to not contain confidential information or unfairly use, may be excluded by filtering lines further including predetermined words through the dictionary verification unit 121c.
  • the dictionary verification unit 121c determines that dictionary verification is necessary for the dicKeyword described in the 7th line of FIG. 12, that is, a line including "password", "pw", and "pass”, It may be determined whether the corresponding line further includes a predetermined word, for example, a word registered in a dictionary and a word frequently used in the source code.
  • the dictionary verification unit 121c may refer to the k-numbered word sets that are frequently used in the source code, and the word set may be updated.
  • a keyword that does not require dictionary verification among keywords may be referred to as a first keyword
  • a keyword that requires dictionary verification may be referred to as a second keyword.
  • the first keyword described above for example, token”, “credential”, “api”, “key”, “credentials”, and “secret”
  • the second keyword for example, “password”, “pw ", and "pass” are exemplary, and may be variously modified.
  • first lines L2a excluding a non-fragile line may be detected by the first line detection unit 121.
  • lines with a high possibility that do not correspond to the weak line L2 are not detected as the first line L2a, so that the FP (false positive) rate of the detected weak lines L2 may be reduced. have.
  • the second line detection unit 122 may detect a line having a specific pattern in order to detect a relatively standardized weak line L2.
  • the pattern may be a pattern of credentials for accessing APIs of various service providers.
  • the second line detection unit 122 may include a pattern-based extraction unit 122a and an entropy verification unit 122b. A method of detecting the second line will be described with further reference to FIG. 6.
  • FIG. 6 is a flowchart of a method of detecting a weak line based on a credential pattern according to an exemplary embodiment.
  • the second line detector 122 may extract lines from among the value assignment lines L1 based on the credential pattern.
  • Different authentication credential patterns for service providers may be different for different service providers. For example, as described in lines 11 to 26 of FIG. 12, different credential patterns may be defined for each service provider.
  • a line including a portion matching the defined credential pattern may be extracted from the value assignment lines L1 through the pattern-based extraction unit 122a. Whether the line includes a portion matching the credential pattern may be determined based on whether the line includes a portion matching the regular expression of the credential pattern.
  • the second line detector 122 determines whether the extracted line is a line requiring entropy verification, and performs entropy verification on the corresponding line. Whether the line needs entropy verification may differ according to the matched credential pattern. For example, as described in lines 12, 15, and 17-24 of FIG. 12, entropy verification may be performed on a line matching a credential pattern in which a value of "entropy" is "true”. Whether to perform entropy verification may be determined based on whether the credential pattern is simple or an identifier indicating that the credential pattern is included in the credential pattern.
  • a line matching the credential pattern generally has a high entropy value, so even if it is detected as a weak line (L2), that is, the second line (L2b), it is almost likely to correspond to FP. Therefore, in this case, the inspection time can be shortened by skipping the entropy verification.
  • the second line detector 122 may filter out a line having a low entropy value among the extracted lines through entropy verification in operations 243 and 244 to be described later.
  • confidential information is composed of a combination of arbitrary strings, and thus has a relatively high entropy value. Even if the line has the same pattern as the defined credential pattern, it is highly likely that the line is not a weak line, or if the pattern has a low entropy value. Accordingly, through entropy verification, a line having a low entropy value is excluded even if it has the same pattern as the defined credential pattern, so that the FP (false positive) rate of the detected weak lines L2 may be reduced.
  • the second line detection unit 122 calculates BASE64 entropy for the extracted line or a portion of the extracted line that matches the credential pattern, and determines whether the calculated value satisfies a predetermined condition. For example, you can determine if it is greater than n1.
  • a line having a BASE64 entropy value greater than n1 may be detected as the second line L2b.
  • n1 may be 3, but is not limited thereto. Since n1 is a number determined through simulation to filter out non-fragile lines in the process of detecting the second line L2b among the value assignment lines L1, n1 may be an appropriate value other than the above-described value.
  • the second line detection unit 122 calculates HEX entropy for a line having a BASE64 entropy value less than n1 or equal to n1, or a portion of the line matching the credential pattern, and the calculated value It is possible to determine whether this predetermined condition is satisfied, for example, greater than n2.
  • a line having a HEX entropy value greater than n2 may be detected as the second line L2b.
  • n2 may be 4.5, but is not limited thereto. Since n2 is a number determined through simulation to filter out non-fragile lines in the process of detecting the second line L2b among the value assignment lines L1, n2 may be an appropriate value other than the above-described value.
  • entropy verification since entropy verification is performed through operations 243 and 244, efficiency of entropy verification may be improved.
  • the second lines L2b of the key assignment lines L1 excluding the non-fragile line may be detected by the second line detector 122. Accordingly, lines with a high possibility that they do not correspond to the weak line L2 are not detected as the second line L2b, and thus the FP (false positive) ratio of the detected weak lines L2 may decrease.
  • the vulnerability of the detected weak lines L2 may be output, which will be described with reference to FIG. 7.
  • FIG. 7 is a block diagram of a vulnerability output unit according to an exemplary embodiment.
  • the vulnerability output unit 130 of the device 100 may include a third line determination unit 131 and a scoring unit 132.
  • the vulnerability of the vulnerable lines L2 detected through the vulnerability output unit 130 of the device 100 may be output.
  • the vulnerability of a line indicates that the line contains, or has been determined to contain, confidential information.
  • the third line determination unit 131 may determine the third line L3 among the weak lines L2 detected through the weak line detection unit 120 in order to remove the FP from among the detected weak lines. . For example, by filtering out the lines repeatedly described in the source code through the third line determination unit 131, non-fragile lines, that is, lines determined to be irrelevant to confidential information or unfairly used may be excluded. . Through this, a rate of false positives (FP) among the detection results may be reduced, and a test time may be shortened.
  • FP false positives
  • the vulnerability may refer to the degree of vulnerability, and the degree of vulnerability may be determined based on the importance of confidential information included in the corresponding line, the existence of a line similar to the corresponding line, the number of similar lines, and the like.
  • the scoring unit 132 may determine the degree of vulnerability of the weak line.
  • the third line determining unit 131 may include a similarity measuring unit 131a and a line classifying unit 131b, and determining a third line through the third line determining unit 131 The method will be described further with reference to FIG. 8.
  • FIG. 8 is a flowchart of a method for classifying lines based on similarity according to an embodiment.
  • the third line determiner 131 may identify detected lines based on a keyword among the detected weak lines L2. That is, the third line determination unit 131 may identify the first lines L2a detected through the first line detection unit 121.
  • the pattern is a combination of arbitrary characters, since the keyword is a word with meaning, the first lines L2a detected based on the keyword have an FP ratio than the second lines L2b detected based on the pattern. It can be high. According to an embodiment, since only the similarity between the first lines L2a is measured, the inspection speed may be improved.
  • the third line determiner 131 may determine a degree of similarity between lines. That is, the third line determiner 131 may determine the degree of similarity between the detected first lines L2a based on the keyword. Since similar lines repeatedly described in the source code have a high probability of being irrelevant to confidential information, the FP ratio may be reduced by filtering out similar lines among the first lines L2a detected based on a keyword.
  • the similarity between the detected first lines L2a may be determined based on the keyword through the similarity measurement unit 131a.
  • the Levenstein distance between lines may be measured, but the present invention is not limited thereto, and other algorithms known to those skilled in the art may be used.
  • the third line determiner 131 may classify similar lines. That is, the third line determiner 131 may classify similar lines among the detected weak lines L2, in particular, among the first lines L2a detected based on the keyword. For example, similar lines among the first lines L2a may be classified based on the Levenstein distance between the first lines L2a.
  • the third line determiner 131 may determine whether the number of classified lines satisfies a predetermined condition, for example, is greater than n3.
  • a line different from another line and similar lines repeated n3 or less may be determined as the third lines L3, excluding similar lines repeated a number of times greater than n3 in the source code. That is, the third line determiner 131 selects a line different from other lines and similar lines repeated n3 or less, excluding similar lines repeated a number of times greater than n3 among the first lines L2a as the third lines ( L3) can be determined.
  • n3 may be 10, but is not limited thereto. Since n3 is a number determined through simulation to filter out non-fragile lines among the first lines L2a, n3 may be an appropriate value other than the above-described value.
  • the vulnerability output unit 130 may output vulnerabilities of specific lines in the source code.
  • the vulnerability output unit 130 may output that the third lines L3 in the source code may be vulnerable.
  • the vulnerability output unit 130 may output that the determined third lines L3 and the second lines L2b among the first lines L2a may be vulnerable.
  • the third line determination unit 131 may be included in the first line detection unit 121.
  • operation 251 may be omitted, and the third line determination unit 131 included in the first line detection unit 121
  • the third lines determined by the second line detection unit 122 are treated as weak lines together with the second lines detected by the second line detection unit 122, so that the vulnerability may be output.
  • the scoring unit 132 may perform predetermined operations related to the line in order to determine the degree of vulnerability of the line.
  • the scoring unit 132 may determine the degree of vulnerability of the third lines L3 determined through the third line determination unit 131.
  • the scoring unit 132 may include a file path and file name classification unit 132a, and a connectivity determining unit 132b, and determining the vulnerability of the weak line through the scoring unit 132 The method will be described further with reference to FIG. 9.
  • FIG. 9 is a flowchart of a method for classifying a level of vulnerability according to an exemplary embodiment.
  • the source code may contain content about the test or example of the application, and the importance of the information contained in the lines about the test or example in the source code may be relatively low. Therefore, if the source code including the detected weak line is related to a test or example, the line can be classified as a low-risk group.
  • the scoring unit 132 may identify the file path and file name of the file including the line.
  • the scoring unit 132 may identify file paths and file names of files including the third lines L3 determined by the third line determination unit 131.
  • the scoring unit 132 may identify file paths and file names of files including the determined third lines L3 and second lines L2b among the first lines L2a.
  • the scoring unit 132 may determine whether the file path or the file name of the file including the line includes a predetermined word.
  • the predetermined word may be "test", “example”, etc., but is not limited thereto. If "test” or “example” is included in the file path or file name of the file, the file has a high probability of jurisdiction over the test or example of the application, so the line included in the file can be classified as a low-risk group. .
  • the degree of vulnerability of the corresponding line may be determined based on whether access to a service provider of the corresponding credential pattern is possible through a line matching the credential pattern.
  • Lines that provide connectivity to service providers may be classified as high-risk groups, and lines that do not are classified as medium-risk groups.
  • the scoring unit 132 may identify whether the line is a detected line based on the credential pattern.
  • the scoring unit 132 may identify whether a line not classified as a low-risk group in operation 262, that is, a line of a file that does not contain a predetermined word in the file path or file name, is a line detected based on the credential pattern have.
  • a line detected based on a keyword may be classified as a low-risk group, and a line detected based on a credential pattern may be classified as a medium-risk group or a high-risk group.
  • the scoring unit 132 may determine the connectivity of the line to the service provider.
  • the line that is not classified as a low-risk group is a line detected based on the credential pattern, that is, when the scoring unit 132 is one of the second lines L2b, through the corresponding line. It is possible to determine whether access to a service provider with a credential pattern matching the line is possible. By testing the connectivity to the service provider only for the detected line based on the credential pattern, the inspection speed can be improved.
  • a line that allows access to the service provider may be classified as a high-risk group, and lines that do not are classified as a medium-risk group.
  • the connectivity determination unit 132b may be included in the second line detection unit 122.
  • operation 263 may be omitted, and the second lines L2b detected by the second line detection unit 122 are Operation 264 may be performed.
  • the file path and file name of the file containing lines that do not provide accessibility to the service provider among the second lines (L2b) are identified, and a predetermined word is included in the file path or file name. Vulnerability of a given line can be output as low risk, a vulnerability of a line that does not have medium risk, and a vulnerability of a line that provides accessibility to a service provider can be output as high risk.
  • FIG. 10 is a block diagram of an automated vulnerability analysis system (AVAS) according to an embodiment.
  • AVAS automated vulnerability analysis system
  • the automatic vulnerability analysis system 1000 may automatically analyze vulnerabilities that may exist in the software development environment. For example, the automatic vulnerability analysis system 1000 may analyze vulnerabilities that may exist in the source code of software developed as open source.
  • the automatic vulnerability analysis system 1000 may include a web portal 1010 and a credential scanner 1020. According to embodiments, the automatic vulnerability analysis system 1000 may include a greater or lesser number of units than the number of units described above. For example, the automatic vulnerability analysis system 1000 may further include various modules for analyzing vulnerability.
  • the device 100 according to an embodiment may be a part of the automatic vulnerability analysis system 1000.
  • the web portal 1010 and the credential scanner 1020 may be implemented in software, hardware, or a combination of software and hardware, but are not limited thereto in order to provide a corresponding service.
  • the web portal 1010 provides an interface for a user to use the automatic vulnerability analysis system 1000, and the credential scanner 1020 examines the source code to determine whether the source code contains confidential information such as credentials. I can.
  • the credential scanner 1020 may detect vulnerabilities in the source code through the methods described above. A series of operations of the credential scanner 1020 may be performed in the device 100 according to an embodiment.
  • the source code is directly uploaded to the credential scanner 1020, or access information indicating the location of the source code or allowing access to the source code, for example, through a uniform resource locator (URL).
  • the source code can be obtained in the credential scanner 1020.
  • Credential scanner 1020 may obtain source code stored in a repository. The repository may be located outside the automatic vulnerability analysis system 1000.
  • the automatic vulnerability analysis system 1000 may include a plurality of servers.
  • the web portal 1010 and the credential scanner 1020 may be implemented as separate servers. Referring to FIG. 11 to describe the automatic vulnerability analysis system 1000 configured as a server.
  • FIG. 11 is a diagram for describing a method of operating a server according to an exemplary embodiment.
  • the automatic vulnerability analysis system 1000 may be implemented with a web portal 1010, a front-end server 1110, a back-end server 1120, and a database 1130.
  • the user may request the automatic vulnerability analysis system 1000 to execute a service and receive a request processing result.
  • the user's client device 2000 may request the front-end server 1110 to execute the service through the web portal 1010, and thereby, the user may request the automatic vulnerability analysis system 1000 to execute the service.
  • a request for detecting a vulnerability in the source code may be transmitted to the front-end server 1110 through the web portal 1010.
  • the front-end server 1110 may directly call a program, process the request, and output the request processing result to the client device 2000 through the web portal 1010, but the front-end server 1110 -The request may be transmitted to the end server 1120 and processed by the back-end server 1120.
  • the request processing result can be transmitted from the back-end server 1120 to the front-end server 1110 and output to the client device 2000 through the web portal 1010, whereby the automatic vulnerability analysis system 1000
  • the request processing result may be provided to the user by the.
  • the back-end server 1120 can access the database 1130 to process requests or store information.
  • the front-end server 1110 may be referred to as a web server.
  • the back-end server 1120 may be referred to as an application server and a web application server.
  • the credential scanner 1020 may be located in the back-end server 1120, but is not limited thereto.
  • the front-end server 1110 and the back-end server 1120 may be implemented as separate servers physically separated in order to distribute the load loaded on the server by separating the function of the server and strengthen security, It is not limited thereto.
  • the front-end server 1110 and the back-end server 1120 may be physically implemented as one server.
  • FIG. 12 shows an exemplary source code of a configuration file of a credential scanner.
  • FIG. 12 has been described with reference to the previous drawings, redundant descriptions will be omitted.
  • the credential scanner can detect weak lines in the source code by referring to the configuration file.
  • the credential scanner basically scans project files in normal mode, but scan efficiency can be improved by scanning specific files in fast mode.
  • Embodiments may be represented by functional block configurations and various processing steps. These functional blocks may be implemented with various numbers of hardware or/and software configurations that perform specific functions. For example, embodiments include integrated circuit configurations such as memory, processing, logic, look-up tables, etc., which can execute various functions by controlling one or more microprocessors or other control devices. Can be adopted. Similar to how each configuration can be implemented with software programming or software elements, embodiments include various algorithms implemented with a combination of data structures, processes, routines or other programming components, including C, C++, Java ( Java), an assembler, or the like may be implemented in a programming or scripting language. Functional aspects can be implemented with an algorithm running on one or more processors.
  • embodiments may employ conventional techniques for electronic environment setting, signal processing, and/or data processing.
  • Terms such as'mechanism','element','means', and'composition' can be widely used, and are not limited to mechanical and physical configurations.
  • the term may include the meaning of a series of routines of software in connection with a processor or the like.
  • connection or connection members of the lines between the components shown in the drawings exemplarily represent functional connections and/or physical or circuit connections, and in an actual device, various functional connections that can be replaced or additionally It may be referred to as a connection, or circuit connections.
  • connection, or circuit connections it may not be a necessary component in the embodiments.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Virology (AREA)
  • Bioethics (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

본 개시에 의해, 방법으로서, 소스 코드를 획득하는 동작; 상기 소스 코드를 파싱하여 값 할당 라인들을 추출하는 동작; 상기 값 할당 라인들 중, 키워드들에 기초하여 제 1 라인들을 탐지하는 동작; 상기 값 할당 라인들 중, 크리덴셜 (credential) 패턴들에 기초하여 제 2 라인들을 탐지하는 동작; 상기 제 1 라인들 중 소정의 조건을 충족하는 라인들의 개수에 기초하여, 상기 제 1 라인들 중 제 3 라인들을 결정하는 동작; 및 상기 제 2 라인들 및 상기 제 3 라인들의 취약성을 출력하는 동작; 을 포함하는 방법이 제공될 수 있다.

Description

소스 코드에서 취약성을 탐지하기 위한 방법, 디바이스, 및 컴퓨터 판독가능 매체
본 개시는 소스 코드에서 취약성 탐지하는 것에 관하고, 구체적으로, 소스 코드에 하드코딩된 (hard coded) 정보로 인한 취약성을 탐지하는 것에 관한다.
소스 코드는 사람이 읽을 수 있는 (human-readable) 프로그래밍 언어로 쓰여진 텍스트로서, 프로그램을 구성하는 요소이다. 컴퓨터는 컴파일러 (compiler) 를 통해 소스 코드를 판독함으로써 프로그램을 실행할 수 있다.
소스 코드는 프로그램의 구조나 알고리즘에 대한 데이터를 포함하므로, 소스 코드가 유출될 경우 해당 프로그램 개발자에게 불리할 수 있다. 하지만, 공중과 기술을 공유하여 프로그램의 신뢰성을 보장하고, 외부 개발자의 참여를 유도하여 다양한 환경에서 프로그램을 시험하기 위해, 소스 코드를 공개하는 오픈 소스 방식으로 프로그램을 개발하는 프로젝트가 증가하고 있다.
소프트웨어가 오픈 소스로 개발되는 경우, 소스 코드에 하드코딩된 (hard coded) 텍스트 또한 모두 공개되므로, 개발자들은 의도치 않게 기밀 정보, 예를 들어, API (application programming interface) 나 특정 정보에 액세스하는데 필요한 인증 정보를 해당 소스 코드에 남겨두지 않도록 조심해야 한다. 하지만, 프로젝트의 규모가 커져 그 프로젝트에 관여하는 사람의 수가 증가할수록, 기밀 정보가 소스 코드에 기록되는 실수가 발생할 가능성이 높아진다.
따라서, 소스 코드에서 취약성을 탐지하기 위한 기술의 개발이 요구되고 있다.
본 개시의 실시예들은, 소스 코드에서 취약성을 탐지하는 기술을 제공하기 위한 것이다.
본 개시에 의해, 방법으로서, 소스 코드를 획득하는 동작; 상기 소스 코드를 파싱하여 값 할당 라인들을 추출하는 동작; 상기 값 할당 라인들 중, 키워드들에 기초하여 제 1 라인들을 탐지하는 동작; 상기 값 할당 라인들 중, 크리덴셜 (credential) 패턴들에 기초하여 제 2 라인들을 탐지하는 동작; 상기 제 1 라인들 중 소정의 조건을 충족하는 라인들의 개수에 기초하여, 상기 제 1 라인들 중 제 3 라인들을 결정하는 동작; 및 상기 제 2 라인들 및 상기 제 3 라인들의 취약성을 출력하는 동작; 을 포함하는 방법이 제공될 수 있다.
상기 소스 코드는, 웹페이지를 통해 사용자로부터 전송된 액세스 정보에 기초하여 획득되는 방법이 제공될 수 있다.
상기 방법은 프로젝트 파일들을 획득하는 동작을 더 포함하고, 상기 소스 코드는 상기 프로젝트 파일들 중 코드 파일에 포함되는 방법이 제공될 수 있다.
상기 소스 코드를 획득하는 동작은, 상기 프로젝트 파일들 중 미디어 파일을 배제하는 동작을 포함하는 방법이 제공될 수 있다.
상기 값 할당 라인들은, 상기 소스 코드를 키 (key), 구분자 (separator), 및 값 (value) 으로 토큰화 (tokenizing) 함으로써 추출되는 방법이 제공될 수 있다.
상기 키워드들은 제 1 키워드 및 제 2 키워드를 포함하고, 상기 제 1 라인들은 상기 제 1 키워드에 연관된 라인을 포함하고, 상기 제 1 라인들을 탐지하는 동작은, 상기 제 2 키워드에 연관되면서 소정의 단어를 포함하는 라인을 배제하는 동작을 포함하는 방법이 제공될 수 있다.
상기 소정의 단어는 사전에 등재된 단어인 방법이 제공될 수 있다.
상기 제 1 라인들을 탐지하는 동작은, 상기 값 할당 라인들 중 상기 키워드들 중 적어도 하나에 연관되면서 암호화되어 있는 라인을 배제하는 동작을 포함하는 방법이 제공될 수 있다.
상기 크리덴셜 패턴들은 서비스 제공자들에 따라 서로 상이한 방법이 제공될 수 있다.
상기 제 2 라인들을 탐지하는 동작은, 상기 크리덴셜 패턴들 중 적어도 하나에 매칭되면서 소정의 엔트로피 조건을 충족하는 라인을 배제하는 동작을 포함하는 방법이 제공될 수 있다.
상기 소정의 조건은 유사도를 포함하는 방법이 제공될 수 있다.
상기 제 3 라인들을 결정하는 동작은, 상기 제 1 라인들 중 상기 소정의 조건을 충족하는 상기 라인들을 개수에 기초하여 상기 라인들을 배제하는 동작을 포함하는 방법이 제공될 수 있다.
상기 소정의 조건을 충족하는 상기 라인들의 개수가 소정의 수보다 큰 경우, 상기 라인들이 배제되는 방법이 제공될 수 있다.
상기 소정의 수는 10인 방법이 제공될 수 있다.
상기 방법은, 상기 제 2 라인들 또는 상기 제 3 라인들을 포함하는 파일들의 파일경로 및 파일이름을 식별하는 동작을 포함하고, 상기 제 2 라인들 및 상기 제 3 라인들의 취약성은, 상기 파일경로 및 상기 파일이름에 기초하여 출력되는 방법이 제공될 수 있다.
파일경로 또는 파일이름에 소정의 단어가 포함된 라인은, 파일경로 또는 파일이름에 상기 소정의 단어가 포함되지 않은 라인보다 더 적은 취약성을 가지는 방법이 제공될 수 있다.
상기 방법은, 상기 제 2 라인들에 기초하여 서비스 제공자들로의 접속성 (connectivity) 을 결정하는 동작을 포함하고, 상기 제 2 라인들의 취약성은 상기 접속성에 기초하여 출력되는 방법이 제공될 수 있다.
상기 취약성은 웹페이지를 통해 사용자에게 제공되는 방법이 제공될 수 있다.
나아가, 본 개시에 의해, 디바이스로서, 인스트럭션들을 저장하는 컴퓨터 판독가능 매체; 및 프로세서를 포함하고, 상기 프로세서는 상기 인스트럭션들을 실행하여: 소스 코드를 획득하는 동작; 상기 소스 코드를 파싱하여 값 할당 라인들을 추출하는 동작; 상기 값 할당 라인들 중, 키워드들에 기초하여 제 1 라인들을 탐지하는 동작; 상기 값 할당 라인들 중, 크리덴셜 (credential) 패턴들에 기초하여 제 2 라인들을 탐지하는 동작; 상기 제 1 라인들 중 소정의 조건을 충족하는 라인들의 개수에 기초하여, 상기 제 1 라인들 중 제 3 라인들을 결정하는 동작; 및 상기 제 2 라인들 및 상기 제 3 라인들의 취약성을 출력하는 동작; 을 수행하도록 구성되는 디바이스가 제공될 수 있다.
나아가, 본 개시에 의해, 인스트럭션들을 저장하는 컴퓨터 판독 가능 매체로서, 상기 인스트럭션들은 프로세서에 의해 실행되는 경우 상기 프로세서로 하여금, 소스 코드를 획득하는 동작; 상기 소스 코드를 파싱하여 값 할당 라인들을 추출하는 동작; 상기 값 할당 라인들 중, 키워드들에 기초하여 제 1 라인들을 탐지하는 동작; 상기 값 할당 라인들 중, 크리덴셜 (credential) 패턴들에 기초하여 제 2 라인들을 탐지하는 동작; 상기 제 1 라인들 중 소정의 조건을 충족하는 라인들의 개수에 기초하여, 상기 제 1 라인들 중 제 3 라인들을 결정하는 동작; 및 상기 제 2 라인들 및 상기 제 3 라인들의 취약성을 출력하는 동작; 을 수행하게 하는 컴퓨터 판독 가능 매체가 제공될 수 있다.
도 1은 일 실시예에 따른 디바이스의 블록도이다.
도 2는 일 실시예에 따른 방법의 흐름도이다.
도 3은 일 실시예에 따른 파싱부의 블록도이다.
도 4는 일 실시예에 따른 취약 라인 탐지부의 블록도이다.
도 5는 일 실시예에 따라 키워드에 기초하여 취약 라인을 탐지하는 방법의 흐름도이다.
도 6은 일 실시예에 따라 크리덴셜 (credential) 패턴에 기초하여 취약 라인을 탐지하는 방법의 흐름도이다.
도 7은 일 실시예에 따른 취약성 출력부의 블록도이다.
도 8은 일 실시예에 따라 유사도에 기초하여 라인들을 분류하는 방법의 흐름도이다.
도 9는 일 실시예에 따라 취약성의 등급을 분류하는 방법의 흐름도이다.
도 10은 일 실시예에 따른 자동 취약성 분석 시스템의 블록도이다.
도 11은 일 실시예에 따른 서버의 동작 방식을 설명하기 위한 도면이다.
도 12는 크리덴셜 스캐너의 설정 파일의 예시적인 소스 코드를 도시한다.
본 명세서에서 사용되는 용어에 대해 간략히 설명하고, 본 발명에 대해 구체적으로 설명하기로 한다.
아래에서는 첨부한 도면을 참고하여 실시예들에 대하여 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나, 실시예들은 다양한 형태로 구현될 수 있으며 여기에서 설명하는 실시예에 한정되지 않는다. 그리고, 도면에서 실시예들을 명확하게 설명하기 위해 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.
용어는 다양한 실시예에 따른 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어들을 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 판례, 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 실시예의 설명 부분에서 상세히 그 의미를 기재할 것이다. 따라서 본 개시에서 사용되는 용어는 단순히 그 용어의 명칭이 아닌, 그 용어가 가지는 의미와 본 개시 전반에 걸친 내용을 토대로 정의되어야 한다.
단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수개의 표현을 포함한다. "포함하다" 또는 "가지다" 등의 용어는 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다. 특히, 숫자들은 이해를 돕기 위한 예로서, 기재된 숫자들에 의해 실시예들이 한정되는 것으로 이해되지 말아야 한다.
또한, 명세서에 기재된 "...부", "모듈" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어 또는 소프트웨어로 구현되거나 하드웨어와 소프트웨어의 결합으로 구현될 수 있다.
명세서 전체에서 비록 "제1", "제2" 등이 다양한 구성요소들을 서술하기 위해서 사용되나, 이들 구성요소들은 이들 용어에 의해 제한되지 않음은 물론이다. 이들 용어들은 단지 하나의 구성요소를 다른 구성요소와 구별하기 위하여 사용하는 것이다. 따라서 이하에서 언급되는 "제1 구성요소"는 실시예의 기술적 사상 내에서 "제2 구성요소"일 수도 있음은 물론이다.
"적어도 하나의"와 같은 표현은, 구성요소들의 리스트 전체를 수식하고, 그 리스트의 구성요소들을 개별적으로 수식하지 않는다. 예를 들어, "A, B, 및 C 중 적어도 하나"는 오직 A, 오직 B, 오직 C, A와 B 모두, B와 C 모두, A와 C 모두, A와 B와 C 전체, 또는 그 조합을 가리킨다.
명세서 전체에서 전자 디바이스는 스마트폰, 태블릿, 휴대폰, PDA (personal digital assistant), 미디어 플레이어, PMP (Portable Multimedia Player), 전자책 단말기, 디지털방송용 단말기, PC (Personal Computer), 노트북 (laptop), 마이크로 서버, GPS (global positioning system) 장치, 네비게이션, 키오스크, MP3 플레이어, 스마트 TV, 디지털 카메라 및 기타 모바일, 또는, 비모바일 컴퓨팅 장치일 수 있으나, 이에 제한되지 않는다.
일 실시예에 따르면, 소스 코드에서 취약 라인이 탐지되고, 탐지된 라인의 취약성이 출력될 수 있다. 따라서, 오픈 소스 프로그램의 소스 코드의 공개 전, 소스 코드의 취약성을 검사함으로써, 기밀 정보 유출로 인한 사고가 예방될 수 있다.
본 개시에서 취약 라인은 소스 코드에서, 기밀 정보, 예를 들어, API (application programming interface) 나 특정 정보에 액세스하는데 필요한 인증 정보를 포함하거나, 포함하는 것으로 결정되는 라인을 가리킨다. 취약 라인이 소스 코드와 함께 공개되는 경우, 취약 라인에 포함된 기밀 정보가 부당이용될(exploited) 수 있다.
본 개시에서 라인의 취약성은, 해당 라인이 기밀 정보를 포함하거나, 포함하는 것으로 결정되었음을 나타낸다. 취약성은 취약성의 정도를 가리킬 수 있으며, 취약성의 정도는, 해당 라인에 포함된 기밀 정보의 중요도, 해당 라인과 유사한 라인의 존재 여부, 유사한 라인들의 수, 등에 기초하여 결정될 수 있다.
도 1은 일 실시예에 따른 디바이스의 블록도이다.
도 1을 참조하면, 일 실시예에 따른 디바이스(100) 는 파싱부 (110), 취약 라인 탐지부 (120), 및 취약성 출력부 (130) 를 포함할 수 있다. 파싱부 (110), 취약 라인 탐지부 (120), 및 취약성 출력부 (130) 는 대응하는 기능을 수행하는 모듈, 예를 들어, 소프트웨어 모듈로 구현될 수 있으나, 이에 제한되지 않고, 하드웨어 모듈로 구현되거나, 하드웨어 모듈과 소프트웨어 모듈의 조합으로 구현될 수 있다.
실시예들에 따라, 디바이스(100)는 전술된 유닛들의 수보다 더 많거나 더 적은 유닛들을 포함할 수 있다. 디바이스(100)에서 수행되는 동작들을 구별하여(distinctively) 설명하기 위해, 디바이스(100)의 유닛들이 개별적으로 명명되었을 뿐이므로, 디바이스(100)에서 수행되는 특정 동작이 반드시 특정 유닛에 의해 수행되는 것으로 이해되지 말아야 한다. 예를 들어, 본 개시에서 디바이스(100)의 특정 유닛에서 수행되는 것으로 묘사된 동작이 다른 유닛에서 수행될 수 있고, 디바이스(100)의 하나의 유닛에서 수행되는 것으로 묘사된 동작이 복수의 유닛들에서 수행될 수 있고, 디바이스(100)의 복수의 유닛들 간의 상호적 처리 (interactive processing) 에 의해 수행되는 것으로 묘사된 동작이 하나의 유닛에 의해 수행될 수도 있다. 나아가, 디바이스(100)에서 수행되는 것으로 묘사된 동작이 다른 디바이스에서 수행되거나, 다른 디바이스의 도움을 받아 수행될 수도 있다.
디바이스 (100) 는 메모리 및 프로세서를 포함할 수 있다. 디바이스 (100) 의 소프트웨어 모듈들, 예를 들어, 프로그램 모듈들은 인스트럭션들의 집합으로서 메모리에 저장될 수 있고, 인스트럭션들이 프로세서에 의해 실행됨으로써 대응하는 기능들이 수행될 수 있다.
파싱부(110)를 통해 정보가 파싱될 수 있다. 예를 들어, 파싱부(110)에 입력된 소스 코드 파일들이 파싱될 수 있다.
취약 라인 탐지부(120)를 통해, 소스 코드에서 취약 라인이 탐지될 수 있다. 취약 라인은, 기밀 정보, 예를 들어, API나 특정 정보에 액세스하는데 필요한 인증 정보를 포함하는 라인을 가리킨다. 취약 라인 탐지부(120)는 소스 코드에서, 암호, 키, 크리덴셜, 토큰, 등에 관련된 텍스트를 포함하는 라인을 탐지할 수 있다. 취약 라인은 소스 코드에서 기밀 정보에 대응하는 텍스트만을 가리키거나, 해당 텍스트를 포함하는 라인을 가리킬 수 있다.
본 명세서에서 라인은, 코드 라인 (lines of code) 뿐만 아니라, 주석 라인 (comment lines) 을 포함할 수 있다. 라인들은 물리적 라인 (physical lines) 뿐만 아니라, 논리적 라인 (logical lines) 으로 구분될 수 있다. 각각의 물리적 라인은 줄 바꿈 여부로 구분될 수 있고, 각각의 논리적 라인은 명령 (command) 으로 구분될 수 있다.
일 실시예에 따르면, 취약 라인 탐지부(120)를 통해, 키워드나 크리덴셜 패턴에 기초하여 소스 코드에서 취약 라인이 탐지될 수 있다.
취약성 출력부(130)를 통해, 탐지된 취약 라인의 취약성이 출력될 수 있다. 라인의 취약성은, 해당 라인이 기밀 정보를 포함하거나, 포함하는 것으로 결정되었음을 나타낸다. 일 실시예에 따르면, 취약성 출력부(130)를 통해, 탐지된 취약 라인들 중 실제로는 취약하지 않은 라인들이 분별되거나, 취약성의 정도에 따라 라인들이 분류될 수 있다.
본 개시의 일 실시예에 따라 소스 코드에서 취약성을 탐지하는 방법은, 도 2를 더 참조하여 설명한다.
도 2는 일 실시예에 따른 방법의 흐름도이다.
동작 210 에서 디바이스(100)는 소스 코드를 획득할 수 있다. 파싱부(110)를 통해 파일로부터 소스 코드가 획득될 수 있다. 복수의 파일들로부터 복수의 소스 코드 세트들이 획득될 수 있다. 소스 코드를 획득하는 방법은 도 3을 참조하여 후술할 것이다.
동작 220 에서 디바이스(100)는 소스 코드에서 값 할당 라인들 (value assignment lines)을 추출할 수 있다. 값 할당 라인들은 소스 코드에서 값이 할당된 라인들을 가리키고, 파싱부(110)를 통해 소스 코드를 파싱함으로써 추출될 수 있다. 소스 코드에서 값 할당 라인들을 추출하는 방법은 도 3을 참조하여 후술할 것이다.
동작 230 에서 디바이스(100)는 값 할당 라인들 중 제 1 라인들을 탐지할 수 있다. 취약 라인 탐지부(120)를 통해, 제 1 라인들이 키워드들에 기초하여 탐지될 수 있다. 제 1 라인을 탐지하는 방법은 도 5를 참조하여 후술할 것이다.
동작 240 에서 디바이스(100)는 값 할당 라인들 중 제 2 라인들을 탐지할 수 있다. 취약 라인 탐지부(120)를 통해, 제 2 라인들이 크리덴셜 (credential) 패턴들에 기초하여 탐지될 수 있다. 제 2 라인을 탐지하는 방법은 도 6을 참조하여 후술할 것이다
동작 250 에서 디바이스(100)는 제 1 라인들 중 제 3 라인들을 결정할 수 있다. 취약성 출력부(130)를 통해, 제 1 라인들 중 소정의 조건을 충족하는 라인들에 기초하여 제 3 라인들이 결정될 수 있다. 제 1 라인들 중 제 3 라인들을 결정하는 방법은 도 8을 참조하여 후술할 것이다.
동작 260 에서 디바이스(100)는 탐지된 라인들의 취약성을 출력할 수 있다. 예를 들어, 취약성 출력부(130)를 통해, 제 1 라인들 및 제 2 라인들의 취약성이 출력될 수 있다. 취약성 출력부(130)를 통해, 제 1 라인들 중 결정된 제 3 라인들, 및 제 2 라인들의 취약성이 출력될 수 있다. 라인들의 취약성 등급을 분류하는 방법은 도 9를 참조하여 후술할 것이다.
본 개시에서 크리덴셜 스캐너는, 소스 코드에서 취약 라인을 탐지하는 프로그램을 가리킬 수 있다.
한편, 실시예들에 따라, 디바이스(100)의 각각의 유닛, 예를 들어, 파싱부 (110), 취약 라인 탐지부 (120), 및 취약성 출력부 (130) 는 각각 하위 유닛들을 포함할 수 있다. 각각의 유닛의 하위 유닛들은 본 개시에서 묘사된 것보다 더 많거나 더 적을 수 있다. 각각의 유닛에서 수행되는 동작들을 구별하여 설명하기 위해 각각의 유닛에서 하부유닛들이 개별적으로 명명되었을 뿐이므로, 각각의 유닛에서 수행되는 특정 동작이 반드시 특정 하부 유닛에 의해 수행되는 것으로 이해되지 말아야 한다. 예를 들어, 본 개시에서 특정 하부 유닛에서 수행되는 것으로 묘사된 동작이 다른 하부 유닛에서 수행될 수 있고, 하나의 하부 유닛에서 수행되는 것으로 묘사된 동작이 복수의 하부 유닛들에서 수행될 수 있고, 복수의 하부 유닛들 간의 상호적 처리 (interactive processing) 에 의해 수행되는 것으로 묘사된 동작이 하나의 하부 유닛에 의해 수행될 수도 있다. 나아가, 특정 유닛에서 수행되는 것으로 묘사된 동작이 다른 유닛에서 수행되거나, 다른 유닛의 도움을 받아 수행될 수도 있다. 유닛과 하위 유닛들은 서로 계층(hierarchy) 관계에 있을 수 있으나, 각각의 유닛에서 수행되는 동작들을 구별하여 설명하기 위해 각각의 유닛에서 하부유닛들이 개별적으로 명명되었을 뿐이므로, 유닛과 하위 유닛들은 서로 계층 관계에 있지 않을 수도 있다.
본 개시의 일 실시예에 따른 디바이스(100)의 각 유닛에서 수행되는 동작들은 도 3 내지 도 9를 참조하여 설명한다.
도 3은 일 실시예에 따른 파싱부의 블록도이다.
도 3에 도시된 바와 같이, 디바이스(100)의 파싱부(110)는 파일 선택부(112), 파일 유형 결정부(114), 및 값 할당 라인 추출부(116)를 포함할 수 있다.
디바이스(100)는 파싱부(110)를 통해 소스 코드 파일들을 획득하여 파싱함으로써, 값 할당 라인들(L1)을 추출할 수 있다. 소스 코드는 파일로부터 획득될 수 있고, 프로젝트 파일들의 집합으로부터 복수의 소스 코드 세트들이 획득될 수 있다. 일 실시예에서, 소스 코드는 웹페이지를 통해 사용자로부터 전송된 액세스 정보에 기초하여 획득될 수 있다. 액세스 정보는 프로젝트 파일들의 위치를 나타낼 수 있고, 디바이스(100)로 액세스 정보를 통해 프로젝트 파일들에 액세스할 수 있다. 프로젝트 파일들은 디바이스(100) 외부의 저장소(repository)에 저장되어 있을 수 있다.
파일 선택부(112)를 통해, 프로젝트 파일들 중 검사될 파일들이 선택되거나 배제될 수 있다. 즉, 선택된 일부 파일들에 대해 검사가 수행되고, 배제된 파일들에 대해서는 검사가 수행되지 않을 수 있다. 따라서, 프로젝트 파일들의 취약성이 효율적으로 탐지될 수 있다. 일 실시예에 따르면, 프로젝트 파일들 중 취약 라인을 포함하지 않을 가능성이 높은 파일들, 예를 들어, 미디어 파일들이 검사에서 배제될 수 있다. 특정 파일들을 검사에서 배제하기 위해, 도 12의 4번째 라인에 기재된 바와 같이 크리덴셜 스캐너의 설정 파일에서, 배제될 파일의 확장자가 설정될 수 있다.
파일 유형 결정부(114)를 통해, 검사되는 파일의 파일 유형이 판별될 수 있다. 파일 유형은 파일의 확장자나 파일 시그니처(signature)에 기초하여 판별될 수 있다. 판별된 파일 유형에 따라 상이한 파서를 이용하여 파일이 파싱될 수 있다. 이때, 파일이 파싱 가능한 지 여부가 결정될 수 있고, 파싱이 가능한 파일만 파싱될 수 있다.
값 할당 라인 추출부 (116) 를 통해, 소스 코드가 파싱되어 소스 코드에서 값 할당 라인들(L1)이 추출될 수 있다. 소스 코드를 키 (key), 구분자(separator), 및 값 (value) 토큰화(tokenizing)함으로써, 값 할당 라인들(L1)이 소스 코드에서 추출될 수 있다. 즉, 값 할당 라인은 키, 구분자, 및 값을 포함하고, 키와 값은 구분자에 의해 구분될 수 있다. 구분자는 도 12의 10번째 라인에 기재된 바와 같이 등호 (=) 또는 콜론 (:) 일 수 있으나, 이에 제한되지 않는다. 구분자는 파싱되는 파일의 파일 유형에 따라 상이할 수 있다.
본 개시의 일 실시예에 따르면, 소스 코드에서 추출된 값 할당 라인들(L1) 중 취약 라인이 탐지될 수 있고, 이는 도 4를 참조하여 설명한다..
도 4는 일 실시예에 따른 취약 라인 탐지부의 블록도이다.
도 4를 참조하면, 디바이스(100)의 취약 라인 탐지부(120)는 제 1 라인 탐지부(121) 및 제 2 라인 탐지부(122)를 포함할 수 있다.
디바이스(100)의 취약 라인 탐지부(120)를 통해 소스 코드의 값 할당 라인들 (L1) 중에서 취약 라인들(L2)이 탐지될 수 있다. 취약 라인들(L2)은 키워드 또는 패턴에 기초하여 탐지될 수 있다. 본 개시에서 키워드에 기초하여 탐지되는 취약 라인(L2)은 제 1 라인으로 지칭될 수 있고, 패턴에 기초하여 탐지되는 취약 라인(L2)은 제 2 라인으로 지칭될 수 있다.
제 1 라인 탐지부(121)는 정형화되지 않거나 정형화되기 어려운 취약 라인(L2)을 탐지하기 위해, 특정 키워드를 포함하는 라인을 탐지할 수 있다. 제 2 라인 탐지부(122)는 상대적으로 정형화된 취약 라인(L2)을 탐지하기 위해, 특정한 패턴을 가지는 라인을 탐지할 수 있다.
일 실시예에서, 제 1 라인 탐지부(121)는 키워드 기반 추출부(121a), 화이트리스트 검증부(121b), 및 딕셔너리 검증부(121c)를 포함할 수 있고, 제 1 라인 탐지부(121)를 통해 키워드에 기초하여 제 1 라인을 탐지하는 방법은 도 5를 더 참조하여 설명한다.
도 5는 일 실시예에 따라 키워드에 기초하여 취약 라인을 탐지하는 방법의 흐름도이다.
동작 231에서 제 1 라인 탐지부(121)는, 소스 코드로부터 추출된 값 할당 라인들 (L1) 중에서, 키워드에 기초하여 라인을 추출할 수 있다. 키워드는 암호, 키, 크리덴셜, 토큰, 등에 관련된 키워드일 수 있다. 예를 들어, 도 12의 6번째 라인의 "Keywords" 에 기재된 바와 같이, 키워드는 "token", "credential", "api", "key", "credentials", 및 "secret"일 수 있으나, 이에 제한되지 않으며, 키워드는 도 12의 7번째 라인의 "dicKeywords"에 기재된 바와 같이, "password", "pw", 및 "pass"를 더 포함할 수 있다. 일 실시예에 따르면, 키워드 기반 추출부(121a)를 통해, 값 할당 라인들(L1) 중 상기 키워드를 포함하는 라인들이 추출될 수 있다. 값 할당 라인들(L1) 중 상기 키워드를 포함하는 라인들을 추출하기 위해, 예를 들어, 다음과 정규 표현식(regular expression)이 이용될 수 있다:
Regex(Key(Keywords, dicKeywords) + Separator(=, :) + Value)
상기 키워드를 포함하는 라인은, API 나 특정 정보에 액세스하는데 필요한 인증 정보와 연관된 라인, 즉 기밀 정보를 포함하는 라인일 확률이 높으므로, 해당 라인이 소스 코드에 포함된 채 공개될 경우 해당 프로그램의 취약점 (vulnerable point)으로 부당이용될(exploited) 수 있다. 따라서, 소스 코드의 공개 전에 이러한 취약 라인(L2)을 미리 탐지함으로써, 기밀 정보 유출로 인한 사고가 예방될 수 있다.
동작 232에서 제 1 라인 탐지부(121)는 추출된 라인이 화이트리스트에 해당하는지를 결정할 수 있다. 값 할당 라인들(L1) 중 키워드를 포함하는 라인이 모두 취약 라인(L2)이 아닐 수 있다. 따라서, 화이트리스트 검증부(121b)를 통해 화이트리스트에 해당하는 라인을 걸러냄(filtering out)으로써, 비취약 라인, 즉, 기밀 정보를 포함하지 않거나, 부당이용될 수 없는 것으로 결정된 라인이 배제될 수 있다. 예를 들어, 도 12의 8번째 라인에 기재된 바와 같이, 암호화된 라인이 화이트리스트에 포함될 수 있다. 라인이 암호화되어 있는지 여부는 해당 라인이 암호화에 연관된 정규 표현식을 포함하는지에 기초하여 결정될 수 있다. 여기서, 암호화된 라인은, 기밀 정보뿐만 아니라, 라인 전체가 암호화된 라인을 가리킬 수 있다. 암호화된 라인은 유출되더라도 취약점으로 부당 이용되기 불가능하거나 어려우므로, 암호화된 라인을 제 1 라인 리스트로부터 제외함으로써, 탐지된 취약 라인들(L2)의 FP (false positive) 비율이 감소할 수 있다.
동작 233에서 제 1 라인 탐지부(121)는 추출된 라인이 딕셔너리 검증이 필요한 라인인지 여부를 결정하여, 해당 라인에 대해 딕셔너리 검증을 수행할 수 있다. 일 실시예에 따르면, 화이트리스트 해당 여부의 결정과 딕셔너리 검증은 그 순서를 바꾸어 수행되거나 병렬적으로 수행될 수 있다.
동작 234에서 제 1 라인 탐지부(121)는 딕셔너리 검증을 통해, 추출된 라인들 중 소정의 단어를 더 포함하는 라인을 걸러낼 수 있다. 즉, 딕셔너리 검증을 통해, 추출된 라인이, 소스 코드에서 빈번하게 사용되고 사전에 등록된 단어를 더 포함하는지가 결정될 수 있다.
값 할당 라인들(L1) 중 키워드를 포함하는 라인이 모두 취약 라인(L2)이 아닐 수 있다. 따라서, 딕셔너리 검증부(121c)를 통해 소정의 단어를 더 포함하는 라인을 걸러냄으로써, 비취약 라인, 즉, 기밀 정보를 포함하지 않거나, 부당이용될 수 없는 것으로 결정된 라인이 배제될 수 있다. 예를 들어, 딕셔너리 검증부(121c)는 도 12의 7번째 라인에 기재된 dicKeyword, 즉, "password", "pw", 및 "pass"를 포함하는 라인에 대해서는, 딕셔너리 검증이 필요한 것으로 결정하여, 해당 라인이 소정의 단어, 예를 들어, 사전에 등록된 단어로서 소스 코드에서 빈번하게 사용되는 단어를 더 포함하는지를 결정할 수 있다. 딕셔너리 검증부(121c)는 소스 코드에서 빈번하게 사용되는 상위 k개의 단어셋을 참조할 수 있으며, 단어셋은 업데이트될 수 있다. "password", "pw", 및 "pass"는 사용자 인터페이스에서 자주 사용되어, 기밀 정보와는 다른 문맥에서 사용될 가능성이 높다. 따라서, 딕셔너리 검증을 통해 "password", "pw", 및 "pass"를 비롯하여, 소스 코드에서 빈번하게 사용되는 사전 등재 단어를 더 포함하는 라인을 배제함으로써, 탐지된 취약 라인들(L2)의 FP (false positive) 비율이 감소할 수 있다.
본 개시에서, 키워드들 중 딕셔너리 검증을 필요로 하지 않는 키워드는 제 1 키워드로 지칭될 수 있고, 딕셔너리 검증을 필요로 하는 키워드는 제 2 키워드로 지칭될 수 있다. 전술된 제 1 키워드, 예를 들어, token", "credential", "api", "key", "credentials", 및 "secret", 그리고, 제 2 키워드, 예를 들어, "password", "pw", 및 "pass"는 예시적이므로, 다양하게 변형될 수 있다.
일 실시예에서, 키 할당 라인들 (L1) 중 비취약 라인을 제외한 제 1 라인들 (L2a)이 제 1 라인 탐지부(121)에 의해 탐지될 수 있다. 일 실시예에 따르면, 취약 라인(L2)에 해당하지 않을 가능성이 높은 라인들은 제 1 라인(L2a)으로 탐지되지 않으므로, 탐지된 취약 라인들(L2)의 FP (false positive) 비율이 감소할 수 있다.
한편, 제 2 라인 탐지부(122)는 상대적으로 정형화된 취약 라인(L2)을 탐지하기 위해, 특정한 패턴을 가지는 라인을 탐지할 수 있다. 여기서 패턴은 다양한 서비스 제공자의 API에 액세스하기 위한 크리덴셜의 패턴일 수 있다.
일 실시예에서, 제 2 라인 탐지부(122)는 패턴 기반 추출부(122a), 및 엔트로피 검증부(122b)를 포함할 수 있고, 제 2 라인 탐지부(122)를 통해 패턴에 기초하여 제 2 라인을 탐지하는 방법은 도 6을 더 참조하여 설명한다.
도 6은 일 실시예에 따라 크리덴셜 (credential) 패턴에 기초하여 취약 라인을 탐지하는 방법의 흐름도이다.
동작 241에서 제 2 라인 탐지부(122)는 크리덴셜 패턴에 기초하여 값 할당 라인들 (L1) 중 라인들을 추출할 수 있다. 서비스 제공자에 상이한 인증 크리덴셜 패턴은 서비스 제공자에 따라 상이할 수 있다. 예를 들어, 도 12의 11번째 라인부터 26번째 라인에 기재된 바와 같이, 서비스 제공자 별로 상이한 크리덴셜 패턴이 정의될 수 있다. 일 실시예에 따르면, 패턴 기반 추출부(122a)를 통해, 값 할당 라인들(L1) 중에서, 정의된 크리덴셜 패턴과 매칭되는 부분을 포함하는 라인이 추출될 수 있다. 라인이 크리덴셜 패턴과 매칭되는 부분을 포함하는지 여부는, 해당 라인이 크리덴셜 패턴의 정규 표현식에 매칭되는 부분을 포함하는지에 기초하여 결정될 수 있다.
동작 242에서 제 2 라인 탐지부(122)는 추출된 라인이 엔트로피 검증이 필요한 라인인지 여부를 결정하여, 해당 라인에 대해 엔트로피 검증을 수행할 수 있다. 엔트로피 검증이 필요한 라인인지 여부는, 매칭된 크리덴셜 패턴에 따라 상이할 수 있다. 예를 들어, 도 12의 12, 15, 17-24번째 라인에 기재된 바와 같이, "entropy"의 값이 "true"인 크리덴셜 패턴에 매칭된 라인에 대해, 엔트로피 검증이 수행될 수 있다. 엔트로피 검증의 수행 여부는 크리덴셜 패턴이 단순한지, 크리덴셜 패턴에 크리덴셜임을 나타내는 식별자가 포함되는지에 기초하여 결정될 수 있다. 즉, 식별자를 포함하지 않음에도 불구하고 크리덴셜 패턴에 매칭되는 라인은 일반적으로 높은 엔트로피 값을 가지므로 취약 라인(L2), 즉, 제 2 라인(L2b)으로 탐지되어도 FP에 해당할 가능성이 거의 없으므로, 이러한 경우 엔트로피 검증을 스킵함으로써 검사 시간이 단축될 수 있다.
제 2 라인 탐지부(122)는 후술되는 동작 243 및 244 에서 엔트로피 검증을 통해, 추출된 라인들 중 엔트로피 값이 낮은 라인을 걸러낼 수 있다. 일반적으로 기밀 정보는 임의의 문자열의 조합으로 구성되므로, 상대적으로 높은 엔트로피 값을 가진다. 정의된 크리덴셜 패턴과 동일한 패턴을 가지는 라인이더라도 해당 라인, 또는 해당 패턴이 낮은 엔트로피 값을 가지는 경우 취약 라인이 아닐 가능성이 높다. 따라서, 엔트로피 검증을 통해, 정의된 크리덴셜 패턴과 동일한 패턴을 가지더라도 낮은 엔트로피 값을 가지는 라인을 배제함으로써, 탐지된 취약 라인들(L2)의 FP (false positive) 비율이 감소할 수 있다.
동작 243 에서 제 2 라인 탐지부(122)는 추출된 라인, 또는, 추출된 라인에서 크리덴셜 패턴과 매칭되는 부분에 대해 BASE64 엔트로피를 계산하여, 계산된 값이 소정의 조건을 충족하는지, 예를 들어, n1보다 큰지를 결정할 수 있다. n1보다 큰 BASE64 엔트로피 값을 갖는 라인은 제 2 라인(L2b)로 탐지될 수 있다. n1은 3일 수 있으나, 이에 제한되지 않는다. n1은 값 할당 라인들 (L1) 중 제 2 라인 (L2b) 를 탐지하는 과정에서 비취약 라인을 걸러내기 위해, 시뮬레이션을 통해 결정된 수이므로, n1은 전술된 값이 아닌 다른 적절한 값일 수 있다.
동작 244 에서 제 2 라인 탐지부(122)는, n1보다 작거나 n1과 동일한 BASE64 엔트로피 값을 갖는 라인, 또는, 그 라인에서 크리덴셜 패턴과 매칭되는 부분에 대해 HEX 엔트로피를 계산하여, 계산된 값이 소정의 조건을 충족하는지, 예를 들어, n2보다 큰지를 결정할 수 있다. n2보다 큰 HEX 엔트로피 값을 갖는 라인은 제 2 라인(L2b)로 탐지될 수 있다. n2는 4.5일 수 있으나, 이에 제한되지 않는다. n2는 값 할당 라인들 (L1) 중 제 2 라인 (L2b) 를 탐지하는 과정에서 비취약 라인을 걸러내기 위해, 시뮬레이션을 통해 결정된 수이므로, n2는 전술된 값이 아닌 다른 적절한 값일 수 있다.
일 실시예에 따르면, 243 및 244 동작들을 통해 엔트로피 검증이 수행되므로, 엔트로피 검증의 효율이 향상될 수 있다.
일 실시예에서, 키 할당 라인들 (L1) 중 비취약 라인을 제외한 제 2 라인들 (L2b)이 제 2 라인 탐지부(122)에 의해 탐지될 수 있다. 이에 따라, 취약 라인(L2)에 해당하지 않을 가능성이 높은 라인들은 제 2 라인(L2b)으로 탐지되지 않으므로, 탐지된 취약 라인들(L2)의 FP (false positive) 비율이 감소할 수 있다.
본 개시의 일 실시예에 따르면, 탐지된 취약 라인들 (L2) 의 취약성이 출력될 수 있고, 이는 도 7을 참조하여 설명한다.
도 7은 일 실시예에 따른 취약성 출력부의 블록도이다.
도 7을 참조하면, 디바이스(100)의 취약성 출력부(130)는 제 3 라인 결정부(131) 및 스코어링(scoring)부(132)를 포함할 수 있다.
디바이스(100)의 취약성 출력부(130)를 통해 탐지된 취약 라인들(L2)의 취약성이 출력될 수 있다. 라인의 취약성은, 해당 라인이 기밀 정보를 포함하거나, 포함하는 것으로 결정되었음을 나타낸다.
탐지된 취약 라인들(L2) 에, 실제로는 기밀 정보와 무관한 라인이 포함될 수 있다. 따라서, 제 3 라인 결정부(131)는 탐지된 취약 라인 중 FP 를 제거하기 위해, 취약 라인 탐지부(120) 를 통해 탐지된 취약 라인들(L2) 중 제 3 라인(L3)을 결정할 수 있다. 예를 들어, 제 3 라인 결정부(131)를 통해 소스 코드에서 반복적으로 기재된 라인을 걸러냄으로써, 비취약 라인, 즉, 기밀 정보와 무관하거나, 부당이용될 수 없는 것으로 결정된 라인이 배제될 수 있다. 이를 통해, 탐지 결과 중 FP (false positive) 비율이 감소하고, 검사 시간이 단축될 수 있다.
한편, 취약성은 취약성의 정도를 가리킬 수 있으며, 취약성의 정도는, 해당 라인에 포함된 기밀 정보의 중요도, 해당 라인과 유사한 라인의 존재 여부, 유사한 라인들의 수, 등에 기초하여 결정될 수 있다. 스코어링부(132)는 취약 라인의 취약성의 정도를 결정할 수 있다.
일 실시예에서, 제 3 라인 결정부(131)는 유사도 측정부(131a), 및 라인 분류부(131b)를 포함할 수 있고, 제 3 라인 결정부(131)를 통해 제 3 라인을 결정하는 방법은 도 8을 더 참조하여 설명한다.
도 8은 일 실시예에 따라 유사도에 기초하여 라인들을 분류하는 방법의 흐름도이다.
동작 251에서 제 3 라인 결정부(131)는, 탐지된 취약 라인들(L2) 중 키워드에 기초하여 탐지된 라인들을 식별할 수 있다. 즉, 제 3 라인 결정부(131)는 제 1 라인 탐지부(121) 를 통해 탐지된 제 1 라인들 (L2a) 을 식별할 수 있다. 패턴은 임의의 문자들의 조합이지만, 키워드는 의미를 갖는 단어이기 때문에, 키워드에 기초하여 탐지된 제 1 라인들 (L2a) 은, 패턴에 기초하여 탐지된 제 2 라인들 (L2b) 보다 FP 비율이 높을 수 있다. 일 실시예에 따르면, 제 1 라인들 (L2a) 간의 유사도만 측정되므로, 검사 속도가 향상될 수 있다.
동작 252에서 제 3 라인 결정부(131)는, 라인들 간의 유사도를 결정할 수 있다. 즉, 제 3 라인 결정부(131)는 키워드에 기초하여 탐지된 제 1 라인들 (L2a) 간의 유사도를 결정할 수 있다. 소스 코드에서 반복되어 기재된 유사한 라인들은 기밀 정보와 무관할 확률이 높으므로, 키워드에 기초하여 탐지된 제 1 라인들 (L2a) 중에서 유사한 라인들을 걸러냄으로써, FP 비율이 감소할 수 있다.
일 실시예에서, 유사도 측정부(131a)를 통해, 키워드에 기초하여 탐지된 제 1 라인들 (L2a) 간의 유사도가 결정될 수 있다. 라인들 간의 유사도를 결정하기 위해 라인들 간의 레벤슈타인 거리가 측정될 수 있으나, 이에 제한되지 않고, 당업자에게 알려진 다른 알고리즘이 사용될 수 있다.
동작 253에서 제 3 라인 결정부(131)는 유사한 라인들을 분류할 수 있다. 즉, 제 3 라인 결정부(131)는 탐지된 취약 라인들 (L2) 중, 특히, 키워드에 기초하여 탐지된 제 1 라인들 (L2a) 중에서 유사한 라인들을 분류할 수 있다. 예를 들어, 제 1 라인들 (L2a) 간의 레벤슈타인 거리에 기초하여, 제 1 라인들 (L2a) 중 유사한 라인들이 분류될 수 있다.
동작 254에서 제 3 라인 결정부(131)는 분류된 라인들의 개수가 소정 조건을 충족하는지, 예를 들어, n3보다 큰지를 결정할 수 있다. 일 실시예에서, 소스 코드에서 n3 보다 큰 횟수로 반복되는 유사한 라인들은 제외하고, 다른 라인과 상이한 라인 및 n3 이하로 반복된 유사한 라인들이 제 3 라인들(L3)로 결정될 수 있다. 즉, 제 3 라인 결정부(131)는 제 1 라인들 (L2a) 중 n3 보다 큰 횟수로 반복되는 유사한 라인들을 제외한, 다른 라인과 상이한 라인 및 n3 이하로 반복된 유사한 라인들을 제 3 라인들(L3)로 결정될 수 있다. n3은 10일 수 있으나, 이에 제한되지 않는다. n3는 제 1 라인들 (L2a) 중 비취약 라인을 걸러내기 위해 시뮬레이션을 통해 결정된 수이므로, n3는 전술된 값이 아닌 다른 적절한 값일 수 있다.
일 실시예에서, 취약성 출력부(130)는 소스 코드에서 특정 라인들의 취약성을 출력할 수 있다. 취약성 출력부(130)는 소스 코드에서 제 3 라인들 (L3) 이 취약할 수 있음을 출력할 수 있다. 취약성 출력부(130)는 제 1 라인들 (L2a) 중 결정된 제 3 라인들 (L3), 및 제 2 라인들 (L2b) 이 취약할 수 있음을 출력할 수 있다.
일 실시예에서, 제 3 라인 결정부(131)가 제 1 라인 탐지부(121)에 포함될 수 있다. 제 3 라인 결정부(131)가 제 1 라인 탐지부(121)에 포함되는 경우, 동작 251 은 생략될 수 있고, 제 1 라인 탐지부(121)에 포함된 제 3 라인 결정부(131)에 의해 결정된 제 3 라인들은, 제 2 라인 탐지부(122)에 의해 탐지된 제 2 라인들과 함께 취약 라인으로 취급되어, 그 취약성이 출력될 수 있다.
한편, 스코어링부(132)는 라인의 취약성의 정도를 결정하기 위해, 해당 라인에 연관된 소정의 동작들을 수행할 수 있다. 스코어링부(132)는 제 3 라인 결정부(131)를 통해 결정된 제 3 라인들(L3)의 취약성의 정도를 결정할 수 있다.
일 실시예에서, 스코어링부(132)는 파일경로 및 파일이름 분류부(132a), 및 접속성 결정부(132b)를 포함할 수 있고, 스코어링부(132)를 통해 취약 라인의 취약성을 결정하는 방법은 도 9를 더 참조하여 설명한다.
도 9는 일 실시예에 따라 취약성의 등급을 분류하는 방법의 흐름도이다.
소스 코드는 애플리케이션의 테스트나 예제에 관한 내용을 포함할 수 있고, 소스 코드에서 테스트나 예제에 관한 라인들에 포함된 정보의 중요도는 상대적으로 낮을 수 있다. 따라서, 탐지된 취약 라인이 포함된 소스 코드가 테스트나 예제에 관한 경우, 해당 라인은 저위험군으로 분류될 수 있다.
동작 261에서 스코어링부(132)는 라인이 포함된 파일의 파일경로 및 파일이름을 식별할 수 있다. 스코어링부(132)는 제 3 라인 결정부(131)에 의해 결정된 제 3 라인들 (L3)을 포함하는 파일들의 파일경로 및 파일이름을 식별할 수 있다. 스코어링부(132)는 제 1 라인들 (L2a) 중 결정된 제 3 라인들 (L3), 및 제 2 라인들(L2b)을 포함하는 파일들의 파일경로 및 파일이름을 식별할 수 있다.
동작 262에서 스코어링부(132)는 라인이 포함된 파일의 파일경로 또는 파일이름이 소정 단어를 포함하는지를 결정할 수 있다. 예를 들어, 소정 단어는 "test", "example", 등일 수 있으나, 이에 제한되지 않는다. 파일의 파일경로 또는 파일이름에 "test", 또는 "example" 이 포함되는 경우, 해당 파일은 애플리케이션의 테스트나 예제에 관할 확률이 높으므로, 해당 파일에 포함된 라인은 저위험군으로 분류될 수 있다.
한편, 크리덴셜 패턴에 매칭되는 라인을 통해, 해당 크리덴셜 패턴의 서비스 제공자로 접속이 가능한지에 기초하여, 해당 라인의 취약성의 정도가 결정될 수 있다. 서비스 제공자로의 접속성을 제공하는 라인은 고위험군으로 분류되고, 그렇지 않은 라인은 중위험군으로 분류될 수 있다.
동작 263에서 스코어링부(132)는 라인이 크리덴셜 패턴에 기초하여 탐지된 라인인지를 식별할 수 있다. 스코어링부(132)는, 동작 262 에서 저위험군으로 분류되지 않은 라인, 즉, 파일경로 또는 파일이름에 소정 단어를 포함하지 않는 파일의 라인이 크리덴셜 패턴에 기초하여 탐지된 라인인지를 식별할 수 있다. 키워드에 기초하여 탐지된 라인은 저위험군으로 분류되고, 크리덴셜 패턴에 기초하여 탐지된 라인은 중위험군 또는 고위험군으로 분류될 수 있다.
동작 264에서 스코어링부(132)는 라인의 서비스 제공자로의 접속성을 결정할 수 있다. 스코어링부(132)는 동작 262에서 저위험군으로 분류되지 않은 라인이, 크리덴셜 패턴에 기초하여 탐지된 라인인 경우, 즉, 제 2 라인들(L2b) 중 하나인 경우, 해당 라인을 통해, 해당 라인과 매칭되는 크리덴셜 패턴의 서비스 제공자로 접속이 가능한지를 결정할 수 있다. 크리덴셜 패턴에 기초하여 탐지된 라인에 대해서만 서비스 제공자로의 접속성을 테스트함으로써, 검사 속도가 향상될 수 있다.
동작 264 에서 서비스 제공자로의 접속성 테스트 결과, 서비스 제공자로 접속을 가능케 하는 라인은 고위험군으로 분류되고, 그렇지 않은 라인은 중위험군으로 분류될 수 있다.
일 실시예에서, 접속성 결정부(132b)가 제 2 라인 탐지부(122)에 포함될 수 있다. 접속성 결정부(132b)가 제 2 라인 탐지부(122)에 포함되는 경우, 동작 263 은 생략될 수 있고, 제 2 라인 탐지부(122)에 의해 탐지된 제 2 라인들(L2b) 에 대해 동작 264 가 수행될 수 있다. 동작 264가 수행된 이후, 제 2 라인들 (L2b) 중 서비스 제공자로의 접속성을 제공하지 않는 라인들이 포함된 파일의 파일경로 및 파일이름을 식별하여, 파일경로 또는 파일이름에 소정 단어가 포함된 라인의 취약성은 저위험을 갖고, 그렇지 않은 라인의 취약성은 중위험을 갖고, 서비스 제공자로의 접속성을 제공하는 라인의 취약성은 고위험을 갖는 것으로 출력될 수 있다.
도 10은 일 실시예에 따른 자동 취약성 분석 시스템 (automated vulnerability analysis system; AVAS)의 블록도이다.
자동 취약성 분석 시스템 (1000) 은 소프트웨어의 개발 환경에서 존재할 수 있는 취약성을 자동으로 분석할 수 있다. 예를 들어, 자동 취약성 분석 시스템 (1000) 은, 오픈 소스로 개발되는 소프트웨어의 소스 코드에 존재할 수 있는 취약성을 분석할 수 있다.
자동 취약성 분석 시스템 (1000) 은 웹 포탈 (1010) 및 크리덴셜 스캐너 (credential scanner)(1020) 를 포함할 수 있다. 실시예들에 따라, 자동 취약성 분석 시스템 (1000) 은 전술된 유닛들의 수보다 더 많거나 더 적은 수의 유닛들을 포함할 수 있다. 예를 들어, 자동 취약성 분석 시스템 (1000) 은 취약성을 분석하기 위한 다양한 모듈들을 더 포함할 수 있다. 일 실시예에 따른 디바이스 (100)는 자동 취약성 분석 시스템 (1000) 의 일부일 수 있다.
웹 포탈 (1010) 및 크리덴셜 스캐너 (1020) 는 대응하는 서비스를 제공하기 위해, 소프트웨어, 하드웨어, 또는 소프트웨어와 하드웨어의 결합으로 구현될 수 있으나, 이에 제한되지 않는다.
웹 포탈 (1010) 은 사용자가 자동 취약성 분석 시스템(1000)을 이용하기 위한 인터페이스를 제공하고, 크리덴셜 스캐너 (1020) 는 소스 코드를 검사하여 소스 코드에 크리덴셜과 같은 기밀 정보가 포함되어 있는지 결정할 수 있다. 크리덴셜 스캐너 (1020) 는 전술된 방법들을 통해 소스 코드에서 취약성을 탐지할 수 있다. 일 실시예에 따른 디바이스 (100) 에서 크리덴셜 스캐너(1020)의 일련의 동작들이 수행될 수 있다.
웹 포탈 (1010) 을 통해, 크리덴셜 스캐너 (1020) 로 소스 코드가 직접 업로드되거나, 소스 코드의 위치를 나타내거나 소스 코드에 액세스하게 하는 액세스 정보, 예를 들어, URL (uniform resource locator) 을 통해 소스 코드가 크리덴셜 스캐너 (1020) 에서 획득될 수 있다. 크리덴셜 스캐너 (1020) 는 저장소 (repository) 에 저장된 소스 코드를 획득할 수도 있다. 저장소는 자동 취약성 분석 시스템 (1000) 외부에 위치할 수 있다.
일 실시예에서 자동 취약성 분석 시스템 (1000) 은 복수의 서버들로 구성될 수 있다. 웹 포탈 (1010) 및 크리덴셜 스캐너 (1020) 는 별도의 서버로 구현될 수 있다. 서버로 구성된 자동 취약성 분석 시스템 (1000) 을 설명하기 위해 도 11을 참조한다.
도 11은 일 실시예에 따른 서버의 동작 방식을 설명하기 위한 도면이다.
자동 취약성 분석 시스템 (1000)은 웹 포탈 (1010), 프론트-엔드 서버(1110), 백-엔드 서버(1120), 및 데이터베이스 (1130) 로 구현될 수 있다.
사용자는 자동 취약성 분석 시스템 (1000) 에게 서비스 실행을 요청하여 요청 처리 결과를 제공받을 수 있다. 사용자의 클라이언트 디바이스 (2000) 는 웹 포탈 (1010) 을 통해 프론트-엔드 서버(1110)에 서비스 실행을 요청할 수 있고, 이로써, 사용자는 자동 취약성 분석 시스템 (1000) 에게 서비스 실행을 요청할 수 있다. 여기서, 소스 코드에서 취약성을 탐지하기 위한 요청이 웹 포탈 (1010) 을 통해 프론트-엔드 서버(1110)에게 전송될 수 있다.
프론트-엔드 서버(1110)는 직접 프로그램을 호출하여, 요청을 처리하고, 웹 포탈 (1010) 을 통해 클라이언트 디바이스(2000)에게 요청 처리 결과를 출력할 수 있으나, 프론트-엔드 서버(1110)로부터 백-엔드 서버(1120)에게 해당 요청이 전달되어 백-엔드 서버(1120)에서 처리될 수도 있다. 요청 처리 결과는 백-엔드 서버(1120)로부터 프론트-엔드 서버(1110)에게 전달되어, 웹 포탈 (1010)을 통해 클라이언트 디바이스(2000)에게 출력될 수 있고, 이로써, 자동 취약성 분석 시스템 (1000) 에 의해 요청 처리 결과가 사용자에게 제공될 수 있다. 백-엔드 서버(1120)는 요청을 처리하거나 정보를 저장하기 위해 데이터베이스 (1130) 에 액세스할 수 있다.
프론트-엔드 서버(1110)는 웹 서버로 지칭될 수 있다. 백-엔드 서버(1120)는 애플리케이션 서버, 웹 애플리케이션 서버로 지칭될 수 있다.
크리덴셜 스캐너(1020)는 백-엔드 서버(1120)에 위치할 수 있으나, 이에 제한되지 않는다.
서버의 기능을 분리하여 서버에 로드되는 부하를 분산시키고 보안을 강화하기 위해, 프론트-엔드 서버(1110) 및 백-엔드 서버(1120)는 물리적으로 분리된 별개의 서버들로 구현될 수 있으나, 이에 제한되지 않는다. 프론트-엔드 서버(1110) 및 백-엔드 서버(1120)는 물리적으로 하나의 서버로 구현될 수도 있다.
도 12는 크리덴셜 스캐너의 설정 파일의 예시적인 소스 코드를 도시한다.
도 12는 이전 도면들을 참조하여 설명되었으므로, 중복 설명은 생략한다.
크리덴셜 스캐너는 설정 파일을 참조하여 소스 코드에서 취약 라인을 탐지할 수 있다. 크리덴셜 스캐너는 기본적으로 노말 모드 (normal mode) 에서 프로젝트 파일들을 검사하지만, 특정 파일들을 패스트 모드 (fast mode) 에서 검사함으로써 검사 효율을 향상시킬 수 있다.
실시예들은 기능적인 블록 구성들 및 다양한 처리 단계들로 나타내어질 수 있다. 이러한 기능 블록들은 특정 기능들을 실행하는 다양한 개수의 하드웨어 또는/및 소프트웨어 구성들로 구현될 수 있다. 예를 들어, 실시예들은 하나 이상의 마이크로프로세서들의 제어 또는 다른 제어 장치들에 의해서 다양한 기능들을 실행할 수 있는, 메모리, 프로세싱, 로직 (logic), 룩업 테이블 (look-up table) 등과 같은 직접 회로 구성들을 채용할 수 있다. 각각의 구성들이 소프트웨어 프로그래밍 또는 소프트웨어 요소들로 실행될 수 있는 것과 유사하게, 실시예들은 데이터 구조, 프로세스들, 루틴들 또는 다른 프로그래밍 구성들의 조합으로 구현되는 다양한 알고리즘을 포함하여, C, C++, 자바 (Java), 어셈블러 (assembler) 등과 같은 프로그래밍 또는 스크립팅 언어로 구현될 수 있다. 기능적인 측면들은 하나 이상의 프로세서들에서 실행되는 알고리즘으로 구현될 수 있다. 또한, 실시예들은 전자적인 환경 설정, 신호 처리, 및/또는 데이터 처리 등을 위하여 종래 기술을 채용할 수 있다. '메커니즘', '요소', '수단', '구성'과 같은 용어는 넓게 사용될 수 있으며, 기계적이고 물리적인 구성들로서 한정되는 것은 아니다. 상기 용어는 프로세서 등과 연계하여 소프트웨어의 일련의 처리들 (routines) 의 의미를 포함할 수 있다.
실시예들은 어떠한 방법으로도 본 개시의 범위를 한정하는 것은 아니다. 명세서의 간결함을 위하여, 종래 전자적인 구성들, 제어 시스템들, 소프트웨어, 상기 시스템들의 다른 기능적인 측면들의 기재는 생략될 수 있다. 또한, 도면에 도시된 구성 요소들 간의 선들의 연결 또는 연결 부재들은 기능적인 연결 및/또는 물리적 또는 회로적 연결들을 예시적으로 나타낸 것으로서, 실제 장치에서는 대체 가능하거나 추가의 다양한 기능적인 연결, 물리적인 연결, 또는 회로 연결들로서 나타내어질 수 있다. 또한, '필수적인', '중요하게' 등과 같이 구체적인 언급이 없다면 실시예들에서 반드시 필요한 구성 요소가 아닐 수 있다.
본 개시, 특히 특허청구범위에서 '상기'의 용어 및 이와 유사한 지시 용어의 사용은 단수 및 복수 모두에 해당하는 것일 수 있다. 또한, 범위 (range) 가 기재된 실시예의 경우 상기 범위에 속하는 개별적인 값을 적용한 것을 포함하는 것으로서 (이에 반하는 기재가 없다면), 상기 범위를 구성하는 각각의 개별적인 값을 기재한 것과 같은 것으로 이해되어야 한다. 실시예에 따른 방법을 구성하는 단계들에 대하여 명백하게 순서를 기재하거나 반하는 기재가 없다면, 상기 단계들은 적당한 순서로 행해질 수 있다. 상기 단계들의 기재 순서에 따라 실시예가 한정되는 것은 아니다. 모든 예들 또는 예시적인 용어 (예들 들어, 등등) 의 사용은 단순히 실시예들을 상세히 설명하기 위한 것으로서 특허청구범위에 의해 한정되지 않는 이상 상기 예들 또는 예시적인 용어로 인해 본 개시의 범위가 한정되는 것은 아니다. 또한, 당업자는 다양한 수정, 조합 및 변경이 부가된 특허청구범위 또는 그 균등물의 범주 내에서 설계 조건 및 팩터에 따라 구성될 수 있음을 알 수 있다.

Claims (15)

  1. 방법으로서,
    소스 코드를 획득하는 동작;
    상기 소스 코드를 파싱하여 값 할당 라인들을 추출하는 동작;
    상기 값 할당 라인들 중, 키워드들에 기초하여 제 1 라인들을 탐지하는 동작;
    상기 값 할당 라인들 중, 크리덴셜 (credential) 패턴들에 기초하여 제 2 라인들을 탐지하는 동작;
    상기 제 1 라인들 중 소정의 조건을 충족하는 라인들의 개수에 기초하여, 상기 제 1 라인들 중 제 3 라인들을 결정하는 동작; 및
    상기 제 2 라인들 및 상기 제 3 라인들의 취약성을 출력하는 동작;
    을 포함하는 방법.
  2. 제 1 항에 있어서,
    상기 소스 코드는, 웹페이지를 통해 사용자로부터 전송된 액세스 정보에 기초하여 획득되는 방법.
  3. 제 1 항에 있어서,
    상기 방법은 프로젝트 파일들을 획득하는 동작을 더 포함하고,
    상기 소스 코드는 상기 프로젝트 파일들 중 코드 파일에 포함되는 방법.
  4. 제 3 항에 있어서,
    상기 소스 코드를 획득하는 동작은, 상기 프로젝트 파일들 중 미디어 파일을 배제하는 동작을 포함하는 방법.
  5. 제 1 항에 있어서,
    상기 값 할당 라인들은, 상기 소스 코드를 키 (key), 구분자 (separator), 및 값 (value) 으로 토큰화 (tokenizing) 함으로써 추출되는 방법.
  6. 제 1 항에 있어서,
    상기 키워드들은 제 1 키워드 및 제 2 키워드를 포함하고,
    상기 제 1 라인들은 상기 제 1 키워드에 연관된 라인을 포함하고,
    상기 제 1 라인들을 탐지하는 동작은, 상기 제 2 키워드에 연관되면서 사전에 등재된 소정의 단어를 포함하는 라인을 배제하는 동작을 포함하는 방법.
  7. 제 1 항에 있어서,
    상기 제 1 라인들을 탐지하는 동작은, 상기 값 할당 라인들 중 상기 키워드들 중 적어도 하나에 연관되면서 암호화되어 있는 라인을 배제하는 동작을 포함하는 방법.
  8. 제 1 항에 있어서,
    상기 크리덴셜 패턴들은 서비스 제공자들에 따라 서로 상이한 방법.
  9. 제 1 항에 있어서,
    상기 제 2 라인들을 탐지하는 동작은, 상기 크리덴셜 패턴들 중 적어도 하나에 매칭되면서 소정의 엔트로피 조건을 충족하는 라인을 배제하는 동작을 포함하는 방법.
  10. 제 1 항에 있어서,
    상기 소정의 조건은 유사도를 포함하는 방법.
  11. 제 1 항에 있어서,
    상기 제 3 라인들을 결정하는 동작은, 상기 제 1 라인들 중 상기 소정의 조건을 충족하는 상기 라인들을 개수가 소정의 수보다 큰 경우 상기 라인들을 배제하는 동작을 포함하는 방법.
  12. 제 1 항에 있어서,
    상기 방법은, 상기 제 2 라인들 또는 상기 제 3 라인들을 포함하는 파일들의 파일경로 및 파일이름을 식별하는 동작을 포함하고,
    상기 제 2 라인들 및 상기 제 3 라인들의 취약성은, 상기 파일경로 및 상기 파일이름에 기초하여 출력되는 방법.
  13. 제 1 항에 있어서,
    상기 방법은, 상기 제 2 라인들에 기초하여 서비스 제공자들로의 접속성 (connectivity) 을 결정하는 동작을 포함하고,
    상기 제 2 라인들의 취약성은 상기 접속성에 기초하여 출력되는 방법.
  14. 디바이스로서,
    인스트럭션들을 저장하는 컴퓨터 판독가능 매체; 및
    프로세서를 포함하고,
    상기 프로세서는 상기 인스트럭션들을 실행하여:
    소스 코드를 획득하는 동작;
    상기 소스 코드를 파싱하여 값 할당 라인들을 추출하는 동작;
    상기 값 할당 라인들 중, 키워드들에 기초하여 제 1 라인들을 탐지하는 동작;
    상기 값 할당 라인들 중, 크리덴셜 (credential) 패턴들에 기초하여 제 2 라인들을 탐지하는 동작;
    상기 제 1 라인들 중 소정의 조건을 충족하는 라인들의 개수에 기초하여, 상기 제 1 라인들 중 제 3 라인들을 결정하는 동작; 및
    상기 제 2 라인들 및 상기 제 3 라인들의 취약성을 출력하는 동작;
    을 수행하도록 구성되는 디바이스.
  15. 인스트럭션들을 저장하는 컴퓨터 판독 가능 매체로서,
    상기 인스트럭션들은 프로세서에 의해 실행되는 경우 상기 프로세서로 하여금,
    소스 코드를 획득하는 동작;
    상기 소스 코드를 파싱하여 값 할당 라인들을 추출하는 동작;
    상기 값 할당 라인들 중, 키워드들에 기초하여 제 1 라인들을 탐지하는 동작;
    상기 값 할당 라인들 중, 크리덴셜 (credential) 패턴들에 기초하여 제 2 라인들을 탐지하는 동작;
    상기 제 1 라인들 중 소정의 조건을 충족하는 라인들의 개수에 기초하여, 상기 제 1 라인들 중 제 3 라인들을 결정하는 동작; 및
    상기 제 2 라인들 및 상기 제 3 라인들의 취약성을 출력하는 동작;
    을 수행하게 하는 컴퓨터 판독 가능 매체.
PCT/KR2020/014747 2019-10-28 2020-10-27 소스 코드에서 취약성을 탐지하기 위한 방법, 디바이스, 및 컴퓨터 판독가능 매체 WO2021085983A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/661,155 US20220253533A1 (en) 2019-10-28 2022-04-28 Method, device, and computer readable medium for detecting vulnerability in source code

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2019-0134487 2019-10-28
KR1020190134487A KR20210050178A (ko) 2019-10-28 2019-10-28 소스 코드에서 취약성을 탐지하기 위한 방법, 디바이스, 및 컴퓨터 판독가능 매체

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/661,155 Continuation US20220253533A1 (en) 2019-10-28 2022-04-28 Method, device, and computer readable medium for detecting vulnerability in source code

Publications (1)

Publication Number Publication Date
WO2021085983A1 true WO2021085983A1 (ko) 2021-05-06

Family

ID=75715387

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2020/014747 WO2021085983A1 (ko) 2019-10-28 2020-10-27 소스 코드에서 취약성을 탐지하기 위한 방법, 디바이스, 및 컴퓨터 판독가능 매체

Country Status (3)

Country Link
US (1) US20220253533A1 (ko)
KR (1) KR20210050178A (ko)
WO (1) WO2021085983A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040096238A (ko) * 2003-05-07 2004-11-16 삼성전자주식회사 소스 코드상에서 ａｐｉ의 예외처리를 검사하는 방법 및시스템
KR101534493B1 (ko) * 2014-11-27 2015-07-07 소프트포럼 주식회사 구조 변환에 기초한 소스코드 보안 약점 탐지 장치 및 방법
US9823922B1 (en) * 2014-12-22 2017-11-21 Amazon Technologies, Inc. Source code mapping through context specific key word indexes and fingerprinting
KR101881271B1 (ko) * 2017-11-15 2018-07-25 한국인터넷진흥원 취약점 정보를 수집하는 장치 및 그 방법
KR20180106742A (ko) * 2017-03-21 2018-10-01 주식회사 한컴시큐어 소스코드 보안 약점 탐지 및 자동 수정 지원 장치와 그 동작 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040096238A (ko) * 2003-05-07 2004-11-16 삼성전자주식회사 소스 코드상에서 ａｐｉ의 예외처리를 검사하는 방법 및시스템
KR101534493B1 (ko) * 2014-11-27 2015-07-07 소프트포럼 주식회사 구조 변환에 기초한 소스코드 보안 약점 탐지 장치 및 방법
US9823922B1 (en) * 2014-12-22 2017-11-21 Amazon Technologies, Inc. Source code mapping through context specific key word indexes and fingerprinting
KR20180106742A (ko) * 2017-03-21 2018-10-01 주식회사 한컴시큐어 소스코드 보안 약점 탐지 및 자동 수정 지원 장치와 그 동작 방법
KR101881271B1 (ko) * 2017-11-15 2018-07-25 한국인터넷진흥원 취약점 정보를 수집하는 장치 및 그 방법

Also Published As

Publication number Publication date
US20220253533A1 (en) 2022-08-11
KR20210050178A (ko) 2021-05-07

Similar Documents

Publication Publication Date Title
WO2017213400A1 (en) Malware detection by exploiting malware re-composition variations
WO2013089340A1 (ko) 어플리케이션의 유사성 검출 장치 및 방법
WO2013168951A1 (ko) 악성 파일 검사 장치 및 방법
WO2013168913A1 (ko) 비실행 파일 검사 장치 및 방법
WO2014035043A1 (ko) 악성 애플리케이션 진단 장치 및 방법
WO2013077538A1 (ko) Ａｐｉ 기반 어플리케이션 분석 장치 및 방법
WO2014088262A1 (ko) 애플리케이션 위/변조 탐지장치 및 방법
WO2018182126A1 (ko) 안전 소프트웨어 인증 시스템 및 방법
WO2018056601A1 (ko) 콘텐츠 파일 접근 제어를 이용한 랜섬웨어 차단 장치 및 차단 방법
WO2012091400A1 (en) System and method for detecting malware in file based on genetic map of file
WO2019231122A1 (ko) 소프트웨어 취약점을 검출하는 전자 장치 및 그 동작 방법
WO2019054613A1 (ko) 바이너리 파일에 기초하여 오픈소스 소프트웨어 패키지를 식별하는 방법 및 시스템
WO2019160195A1 (ko) 파일 내 포함된 악성 위협 탐지 장치 및 방법, 그 기록매체
US10482240B2 (en) Anti-malware device, anti-malware system, anti-malware method, and recording medium in which anti-malware program is stored
WO2018016671A2 (ko) 보안 취약점 점검을 위한 위험성 코드 검출 시스템 및 그 방법
WO2019066222A1 (ko) 바이너리 파일에 기초하여 오픈소스 소프트웨어 패키지를 식별하는 방법 및 시스템
WO2022260254A1 (ko) 전이학습을 통한 적응형 모델 기반의 온 디바이스 안드로이드 악성코드 탐지 방법, 이를 수행하기 위한 기록 매체 및 장치
WO2018194196A1 (ko) Elf 파일의 난독화 적용 여부의 탐지 및 보안성 평가를 위한 방법 및 시스템
EP4010841A1 (en) System and method for solving text sensitivity based bias in language model
WO2022108318A1 (ko) 스마트 컨트랙트 코드 취약점 분석 장치 및 방법
Yang et al. Automated identification of sensitive data from implicit user specification
WO2017200239A2 (ko) 지문 정보를 포함하는 터치 입력에 기반한 사용자 인증 방법 및 장치
WO2021085983A1 (ko) 소스 코드에서 취약성을 탐지하기 위한 방법, 디바이스, 및 컴퓨터 판독가능 매체
WO2022107964A1 (ko) 인접 행렬 기반의 악성 코드 탐지 및 분류 장치와 악성 코드 탐지 및 분류 방법
WO2018199366A1 (ko) 덱스 파일의 난독화 적용 여부의 탐지 및 보안성 평가를 위한 방법 및 시스템

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20883562

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20883562

Country of ref document: EP

Kind code of ref document: A1