이미 알고 있는 내용들이지만, 이번 기회에 이것저것 정리를 해보려고 한다.

function visibility

1) public

: external + internal

2) external

: external call만 가능

3) internal

: internal call (상속받은 child contract 포함)

4) private

: internal call (상속받은 경우 접근 불가능)

variable visibility

1) public

자동으로 getter function이 생성됨

2) internal

contract 내부, 상속받은 contract

3) private

contract 내부에서만 가능 (상속받은 경우 불가능)

Default visibility 취약점 (0.5.0 이전)

1) visibility를 쓰지 않은 경우

0.5.0 이전의 경우 자동으로 public으로 설정됨

2) private 대신 public을 쓰는 경우

3) internal 대신 external을 쓰는 경우

예시

예시1)

여기서 _sendETH가 internal로 설정되지 않아 누구나 withdraw가 가능해진다.

(이 코드는 visibility를 쓰지 않아 물론 0.5.0 이전에서만 컴파일된다)

예시2) Parity Wallet

$31M이 털렸다고 한다

함수에 visibility가 없어 owner 권한을 탈취할 수가 있었다.

Access Control 취약점

예시1)

실제로 2022년 6월에 털린 컨트랙트의 코드라고 한다.

예시2)

immunify에서 찾아진 취약점으로, $42k를 보상으로 받았다고 한다.

external로 선언되어 누구나 init을 호출할 수 있다.

예시3)

_burn이 external로 선언되어 있다.

Best Practice

1. 항상 visibility를 체크할 것

2. sensitive function들은 반드시 access control을 붙일 것

3. Attacker의 mindset으로 코드를 리뷰할 것

4. Access Control을 직접 만들지 말 것! (바퀴의 재발명 X)
   -> 가급적 Openzeppelin에서 만든 라이브러리를 사용할 것!

Openzeppelin libirary

Ownable.sol

• 공식문서
• 코드

owner만 접근할 수 있는 onlyOwner modifier를 제공하는 라이브러리이다.

default로 deployer의 주소가 등록된다

AccessControl.sol

• 공식문서
• 코드

onlyRole modifier를 제공한다.

Ownable의 onlyOwner의 경우에는 msg.sender가 owner인지만 체크하는데,

onlyRole의 경우 특정 msg.sender가 특정 role을 갖고있는지를 체크한다.