Storage

Yasca

2007년 Michael이 개발하였으며, 소스코드에 대한 보안 취약점 점검과 품질향상을 위한 오픈소스이며 시큐어 코딩 점검 툴입니다.

yasca 지원언어 Java, C/C++, ASP, PHP 등 다양한 언어를 지원하고있습니다.

yasca 다운로드

https://sourceforge.net/projects/yasca/files/Yasca%202.x/Yasca%202.2/

위 URL에서 다운로드 받을 수 있으며, 저는 yasca-core-2.21.zip을 다운로드받았습니다.

원하는 경로에 압축을 풀고 실행 및 실행확인

원하는 경로에 압축을 풀어주시고 cmd창에서 해당경로로 이동합니다.

해당경로에서 yasca를 입력하시면 yasca와 관련된 정보들이 출력되면 성공한 것입니다.

yasca를 이용한 소스코드분석

yasca –px jlint,Lint4j [검사 할 소스코드 경로]

yasca -px jlint,Lint4j D:\프로젝트경로

cmd창에서 위와 같이 입력해주시면 해당 소스를 점검해줍니다.

결과생성

위에까지 진행하셨다면 분석이 완료되면 cmd창에서 맨마지막줄에 아래와 같이 경로와 완료된 html파일명이 표시됩니다.

WARN Results have been written to C:\Users\Yasca\Yasca-Report-날짜.html

해당 폴더로가서 html파일을 실행해주시면 됩니다.

그러면 아래 사진과 같은 화면이 나옵니다.

 맨 우측은 해당하는 소스가 나오고 그 좌측에 네모버튼의 의미는 아래와 같고 누르시면 확인하실 수 있습니다.

- 회색 :　취약점 번호에 “검토결과 취약점 아님”라는 의미의 라인표시

- 붉은색 : 검사 소스코드에서 발견된 취약점 설명

- 파란색 : 취약점이 발견된 소스코드의 위치 확인 

SQL인젝션이란?

웹 애플리케이션 사용자의 입력 값에 필터링이 제대로 적용돼 있지 않을 때 발생합니다. 공격자는 사용자의 입력 값을 조작해 개발자가 의도치 않은 SQL문을 실행하게 만들어 데이터베이스를 공격하는 것을 SQL인젝션이라고 합니다.

SQL이란?

SQL은 데이터베이스(DB)를 만들고 유지하는 데 사용하는 프로그래밍 언어 중 하나입니다. DB를 구축하고 조작하기 위해 사용하는 일종의 명령어인 셈입니다. SQL을 이용하면 데이터를 정의, 조작, 제어할 수 있습니다.

SQL인젝션의 2가지공격인 에러 기반 공격과 블라인드 공격

에러 기반 공격은 해커가 검사하지 않은 입력값을 발견하고, 이를 악용할 때 발생하는 공격이다. 검사 입력값은 입력한 데이터 중에서 불필요한 부분을 제거하는데, 해커는 잘못된 정보를 입력하고 피드백을 기다리기만 하면 그 정보를 가로채는 방식입니다.

블라인드 공격은 에러 기반 공격과 달리 DB 서버 에러 메시지를 이용하지 않고 바로 DB를 공격한다. 에러 메시지가 정보가 아무런 도움이 되지 않을 때 사용한다. 대표적인 기술로는 시간 지연 공격이 있다. 간단하게 몇 초 정도의 time for delay 를 이용해 원하는 시간 만큼 데이터베이스가 움직여 준다면 취약하다고 볼 수 있습니다.

이 공격은 DB 취약점을 노리고 공격하는 기법보다 성공하기 어렵긴 하지만, 꾸준히 발생하는 공격 중 하나입니다.

SQL 인젝션 공격

로그인 폼에 아이디와 비밀번호를 입력하면 입력한 값이 서버로 넘어가고, 데이터베이스를 조회하여 정보가 있다면 로그인에 성공하게 됩니다. 이때 데이터베이스에 값을 조회하기 위해 사용되는 SQL문이 아래와 같을때

SELECT user FROM user_info WHERE id='입력한 아이디' AND pw='입력한 비밀번호';

보통 사용자라면 아이디와 비밀번호를 입력하고 거기에 해당하는 정보가 DB에 있다면 로그인이 될 것이고 아니면 ‘아이디나 비밀번호가 틀렸다’는 메시지를 받을 것입니다.

하지만 여기서 SQL인젝션 공격을 한다면 아래와 같이

SELECT user FROM user_info WHERE id='입력한 아이디' AND pw=' ' OR '1' = '1';

비밀번호 입력란에 ' OR '1' = '1 입력해서 pw의 값을 무효화 시켜 로그인이 성공하게 만들어 버립니다.

로그인 폼도 결국엔 서버에 요청을 해서 받는 것입니다. http헤더를 보면 응답 헤더에 서버의 종류와 버전이 나온다. Apache서버는 mysql서버,iis는 ms-sql같은 방식으로 데이터베이스의 종류를 추측할 수 있습니다. DB엔진을 알아내서 해당 시스템에 맞는 명령어를 이용해 데이터를 뽑아내거나 할수 있습니다.

방어법

아마도 XSS와 상당부분 겹치겠지만 기본적으로 유저에게 받은 값을 직접 SQL로 넘기면 안 됩니다. 요즘에 쓰이는 거의 모든 데이터베이스 엔진은 유저 입력이 의도치 않은 동작을 하는 걸 방지하는 escape 함수와 prepared statement를 제공하는데 이것을 사용합니다. (prepared statement 자체 내에 escape가 내장돼서 한 겹 감싸진 형태)

또한 DB에 유저별로 접근 권한과 사용 가능한 명령어를 설정하면 최악의 경우에 SQL injection에 성공하였다고 하더라도 그나마 피해를 최소화 할 수 있습니다. 혹자는 SQL injection은 데이터베이스 스키마를 알아야 가능한 공격기법이라고 하지만 그 스키마 자체를 SQL injection으로 알아낼 수가 있습니다. 그리고 데이터베이스를 변조하려는 게 아니라 파괴하려는 거라면 와일드카드를 사용해서 그냥 싹 다 지워버리는 공격이 가능합니다.

DB엔진별로 문법이 다 다르기 때문에 개발자가 그걸 다 고려해서 코딩하는 방법은 매우 비추천 됩니다. 엔진에서 제공하는 prepared statement를 사용하는 게 최선. escape_string같은 함수를 사용하면 몇몇 군데에서 빼먹거나 하는 실수로 보안 구멍이 생길 수 있다. 그리고 prepared statement는 사용 전에 일부 컴파일 되서 DB쿼리를 가속시켜주므로 적극적으로 사용하자. 다만 컴파일하는 시간이 있다 보니 변수만 다른 같은 쿼리를 반복적으로 하는 작업에서야 유의미한 속도 향상이 있습니다.

추천되는 방어법은 클라이언트측 자바스크립트로 폼 입력값을 한 번 검증하고(이때의 폼 검증은 사용자에게 인젝션관련 특수문자 사용을 불가능하다고 알리는 용도로 방어방법과는 관련이 없다는 걸 유의), 서버측은 클라이언트측 필터가 없다고 가정하고(공격자가 자바스크립트를 꺼버리거나 폼 페이지를 다운받아 마개조하면 그만) 한번 더 입력 값을 필터링합니다. 이때 정규표현식으로 필터링하는게 가장 강력하고 좋습니다. 그 다음 SQL 쿼리로 넘길 때 해당 파라미터를 prepared statement로 입력한다. 다음, 쿼리의 출력값을 한번 더 필터링하고(XSS 공격 방어의 목적이 강하다) 유저에게 전송합니다. 이렇게 하면 해당 폼에 대해서는 SQL injection공격이 완전히 차단됩니다. 물론 이것이 공격 기법의 전부가 아니므로(스푸핑이나 맨 인 미들 공격, 키 로거 등등) 정보 유출에 민감한 사이트를 운영할 생각이라면 보안 회사에 컨설팅을 꼭 받는게 좋을 것 같습니다.

-나무위키 SQL인젝션, google검색 참조

1. pom.xml dependency 추가

<dependency> 

<groupId>com.navercorp.lucy</groupId>

<artifactId>lucy-xss-servlet</artifactId> 

<version>2.0.0</version> 

</dependency>

2. web.xml 설정

<filter> 

<filter-name>xssEscapeServletFilter</filter-name> 

<filter-class>com.navercorp.lucy.security.xss.servletfilter.XssEscapeServletFilter</filter-class> 

</filter> 

<filter-mapping> 

<filter-name>xssEscapeServletFilter</filter-name> 

<url-pattern>/*</url-pattern> 

</filter-mapping>

3. /resource 폴더 내에 "lucy-xss-servlet-filter-rule.xml" 파일을 생성

lucy-xss-servlet-filter-rule.xml

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns="http://www.navercorp.com/lucy-xss-servlet">

   <defenders>

       <!-- XssPreventer 등록 -->

       <defender>

           <name>xssPreventerDefender</name>

           <class>com.navercorp.lucy.security.xss.servletfilter.defender.XssPreventerDefender</class>

       </defender>

       <!-- XssSaxFilter 등록 -->

       <defender>

           <name>xssSaxFilterDefender</name>

           <class>com.navercorp.lucy.security.xss.servletfilter.defender.XssSaxFilterDefender</class>

           <init-param>

               <param-value>lucy-xss-sax.xml</param-value>   <!-- lucy-xss-filter의 sax용 설정파일 -->

               <param-value>false</param-value>        <!-- 필터링된 코멘트를 남길지 여부, 성능 효율상 false 추천 -->

           </init-param>

       </defender>

       <!-- XssFilter 등록 -->

       <defender>

           <name>xssFilterDefender</name>

           <class>com.navercorp.lucy.security.xss.servletfilter.defender.XssFilterDefender</class>

           <init-param>

               <param-value>lucy-xss.xml</param-value>    <!-- lucy-xss-filter의 dom용 설정파일 -->

               <param-value>false</param-value>         <!-- 필터링된 코멘트를 남길지 여부, 성능 효율상 false 추천 -->

           </init-param>

       </defender>

   </defenders>

    <!-- default defender 선언, 별다른 defender 선언이 없으면 default defender를 사용해 필터링 한다. -->

    <default>

        <defender>xssPreventerDefender</defender>

    </default>

    <!-- global 필터링 룰 선언 -->

    <global>

        <!-- 모든 url에서 들어오는 globalParameter 파라메터는 필터링 되지 않으며 

                또한 globalPrefixParameter로 시작하는 파라메터도 필터링 되지 않는다. -->

        <params>

            <param name="globalParameter" useDefender="false" />

            <param name="globalPrefixParameter" usePrefix="true" useDefender="false" />

        </params>

    </global>

    <!-- url 별 필터링 룰 선언 -->

    <url-rule-set>

       <!-- url disable이 true이면 지정한 url 내의 모든 파라메터는 필터링 되지 않는다. -->

       <url-rule>

           <url disable="true">/disableUrl1.do</url>

       </url-rule>

        <!-- url1 내의 url1Parameter는 필터링 되지 않으며 또한 url1PrefixParameter로 시작하는 파라메터도 필터링 되지 않는다. -->

        <url-rule>

            <url>/url1.do</url>

            <params>

                <param name="url1Parameter" useDefender="false" />

                <param name="url1PrefixParameter" usePrefix="true" useDefender="false" />

            </params>

        </url-rule>

        <!-- url2 내의 url2Parameter1만 필터링 되지 않으며 url2Parameter2는 xssSaxFilterDefender를 사용해 필터링 한다.  -->

        <url-rule>

            <url>/url2.do</url>

            <params>

                <param name="url2Parameter1" useDefender="false" />

                <param name="url2Parameter2">

                    <defender>xssSaxFilterDefender</defender>

                </param>

            </params>

        </url-rule>

    </url-rule-set>

</config>

*표준프레임워크 공통컴포넌트에서는HTMLTagFilter를 제공하고 있으니 확인하려면 web.xml에서 HTMLTagFilter(필터, 필터매핑)을 주석처리해주면 됩니다.

lucy에 관련된 자세한 정보는 Naver Git인 https://github.com/search?q=org%3Anaver+lucy 에서 찾으실 수 있습니다.

XSS란?

웹 상에서 가장 기초적인 취약점 공격 방법의 일종으로, 악의적인 사용자가 공격하려는 사이트에 스크립트를 넣는 기법을 말한다. 공격에 성공하면 사이트에 접속한 사용자는 삽입된 코드를 실행하게 되며, 보통 의도치 않은 행동을 수행시키거나 쿠키나 세션 토큰 등의 민감한 정보를 탈취한다. xss는 크로스 사이트 스크립팅이라고도 부르며 일반적으로 자바스크립트에서 발생하지만, VB 스크립트, ActiveX 등 클라이언트에서 실행되는 동적 데이터를 생성하는 모든 언어에서 발생이 가능하다.

XSS공격

XSS 취약점을 이용한 공격 방법은 3가지로 분류된다.

1. 저장 XSS 공격

2. 반사 XSS 공격

3. DOM기반 XSS 공격

1. 저장 XSS 공격

접속자가 많은 웹 사이트를 대상으로 공격자가 XSS 취약점이 있는 웹 서버에 공격용 스크립트를 입력시켜 놓으면, 방문자가 악성 스크립트가 삽입되어있는 페이지를 읽는 순간 방문자의 브라우저를 공격하는 방식. 가장 일반적인 방법은 게시판 같은 곳에 HTML 문서에 과 같은 태그를 포함한다. 이 경우에 게시판에는 태그가 나타나지 않으며 사용자는 확인할 수가 없다.

2. 반사 XSS 공격

악성 스크립트가 포함된 URL을 사용자가 클릭하도록 유도하여 URL을 클릭하면 클라이언트를 공격하는 것을 반사 XSS공격이라고 한다.

반사식 XSS 공격은 웹 애플리케이션의 지정된 변수를 이용할 때 발생하는 취약점을 이용하는 것으로, 검색 결과, 에러 메시지 등 서버가 외부에서 입력 받은 값을 받아 브라우저에게 응답할 때 전송하는 과정에서 입력되는 변수의 위험한 문자를 사용자에게 그대로 돌려주면서 발생한다. 일반적으로 서버에 검색 내용을 입력하면, 검색 결과가 있는 경우에는 결과 값을 사용자에게 전달하지만, 서버에서 정확한 결과가 없는 경우 서버는 브라우저에 입력한 값을 그대로 HTML 문서에 포함하여 응답한다. 이 경우 HTML 페이지에 포함된 악성 스크립트가 브라우저에서 실행이 된다.

3. DOM기반 XSS 공격

악성 URL을 통해 사용자의 브라우저를 공격하는 것이 DOM 기반 XSS공격이다.

피해자의 브라우저가 HTML 페이지를 구문 분석할 때마다 공격스크립트가 DOM 생성의 일부로 실행되면서 공격한다. 페이지 자체는 변하지 않으나,

페이지에 포함되어 있는 브라우저측 코드가 DOM 환경에서 악성코드로 실행된다.

앞에서 다룬 저장 XSS 및 반사 XSS 공격의 악성 페이로드가 서버 측 애플리케이션 취약점으로 인해, 응답 페이지에 악성 스크립트가 포함되어 브라우

저로 전달되면서 공격하는 것인 반면, DOM 기반 XSS는 서버와 관계없이 브라우저에서 발생하는 것이 차이점이다.

Xss 방어기법

1. 입・출력 값 검증 및 무효화

2. 보안 라이브러리

3. 브라우저 확장 프로그램

1. 입・출력 값 검증 및 무효화

XSS 취약점을 근본적으로 제거하기 위해서는 스크립트 등 해킹에 사용될 수 있는 코딩에 사용되는 입력 및 출력 값에 대해서 검증하고 무효화시켜야 한다. 입력 값에 대한 유효성 검사는 데이터가 입력되기 전에 가능하면, 입력 데이터에 대한 길이, 문자, 형식 및 사업적 규칙 유효성을 검사해야 한다. 출력 값을 무효화하기 위해서는 XSS 공격은 기본적으로 HTML “<”로 변경한다. HTML 엔터티는 대부분의 인터프리터(특히, 브라우저)에서 특수한 FOCUS 의미를 가지지 않으며, 단순한 문자로 처리된다. 이렇게 인코딩하면 사용자는 <script>가 <script>로 보이지만 HTML 문서에서는 &lt;script&gt;로 나타나서 브라우저에서 일반 문자로 인식하고 스크립트로 해석되어 실행되지는 않는다.

2. 보안 라이브러리

1) AntiXSS AntiXSS 라이브러리

마이크로소프트사에서 개발한 공개용 XSS 취약점 예방 라이브러리이다. AntiXSS 라이브러리는 ASP.net 애플리케이션 개발환경에서 사용되며, 현재 ASP.net 4.5 이후 버전에만 사용이 가능하다. 이 라이브러리는 입력 값을 검증하여 서버로 악성 스크립트로 입력되지 못하는 기능과 위험한 문자를 인코딩하는 함수를 제공한다.

2) OWASP ESAPI 라이브러리 OWASP

포괄적인 애플리케이션 보안을 위해 웹 응용 취약점을 대응할 수 있는 오픈소스 ESAPI 라이브러리를 개발하여 제공하고 있다. ESAPI에는 총 14개의 API가 있으며, 이 중 XSS 취약점을 예방하기 위해 API는 validator와 encoder가 있다. validator는 입력 값을 필터링하는 기능을 하고 있으며, encoder는 출력 값을 인코딩 및 디코딩 기능을 가지고 있다. 이 라이브러리는 자바, PHP, .NET, ASP, 자바스크립트 및 파이썬 등 다양한 애플리케이션 개발 언어를 지원하고 있다.

3) NAVER Lucy

NAVER에서 개발한 라이브러리이며, 파라미터로 받은 문자열을 단순히 escape 하는 XssPreventer와 xml기반의 화이트리스트 필터링 방식을 사용하며, 화이트리스트 상위설정 파일에 대해 상속 오버라이딩이 가능하고, 상속받아서 적용할 수 있고 서비스에 따라 변경이 불가피한 필터링 규칙은 하위 파일에서 재정의 할 수 있어 서비스에 맞게 수정가능한 XSS Filter, Xss-servlet-Filter이 있습니다.

3. 브라우저 확장 프로그램

애플리케이션 개발 시 이용하는 라이브러리 이외에도 사용자가 XSS 공격을 예방할 수 있는 프로그램도 있다. NoScript는 파이어폭스 등 모질라 기반의 브라우저에서 실행되는 오픈 소스 확장 프로그램으로, 화이트 리스트 기반으로 신뢰된 사이트의 자바스크립트, 플래쉬, 실버라이트 및 액티브X 등 동적 스크립트만 브라우저에서 실행하도록 하여 XSS 공격을 예방할 수 있습니다.

1. Cross Site Scripting(크로스 사이트 스크립팅)  = XSS공격

게시판이나 웹 메일 등에 악의적인 스크립트를 삽입하여 비정상적인 페이지가 보이게해 타 사용자의 사용을 방해하거나 쿠키 및 기타 개인정보를 특정 사이트로 전송하는등의 문제

2. SQL Injection(SQL문 삽입공격)

웹어플리케이션에 의도적으로 sql문을 삽입하여 로그인 인증과정을 우회하거나 공격자의 악의적인 쿼리문을 DB에 보낼수 있는 문제

3. Parameter Manipulation(파라미터 변조)

웹어플리케이션이 사용자의 파라미터값을 검증하지 않을경우 이를 악용하여  어플리케이션이 비정상적으로 동작하게끔 하는 문제

4. Brute Force Attacks(반복[사전식]공격)

Get이나 Post방식으로 인증하는 페이지에서 특정 ID에 대해 패스워드를 무한 입력하여 해당 ID의 패스워드를 획득할수 있는 문제

5. Buffer Overflows(버퍼오버플로우)

웹서버에서 구동되는 실행파일에 비정상적인 버퍼 값을 입력시켜 시스템을 다운 시키거나 관리자권한을 획득하는 문제

6. Session Hijacking/Cookie Spoofing (세션 가로채기,쿠키변조)

웹 어플리케이션과 클라이언트간 주고받는 정보를 임의적으로 변경하거나 쿠키정보를 변조하여 인증을 회피하거나 중요정보를 획득하는 문제

7. User Cgi Upload(사용자cgi 업로드)

사용자가 악의적인 목적으로 웹어플리케이션에서 수행가능한 cgi프로그램을 (asp,jsp,php,perl등)업로드하여 서버를 공격하는 문제

8. Remote Administration Flaws(관리자 페이지 접속 공격)

인터넷상에 공개된 관리자 페이지를 다양한 방법으로 공격하여 관리자권한 획득을 시도하는 문제

9.  Directory/Path Traversal (디렉토리/경로 탐색)

웹서버 설정상의 오류나 중요 파일의 위치오류를 이용하여 디렉터리 리스팅을 통해 특정파일에 접근하거나 중요정보를 획득할수있는 문제

WEB공격들은 종래의 OS공격과는 달리 다음과 같은 몇가지 특징들이 있습니다.

- 방화벽,IDS등 기존의 보안대책으로는 대응하기 어렵다.

- 반드시 서버관리자 권한을 뺐는것이 목적이 아니다.

- 각 WEB어플리케이션마다 공격의 패턴이 다르다.

- 바이러스나 웜이 아니므로 백신에서 탐지되지 않는다.

- 대부분 공격의 흔적이 로그에 남지않는다.