Hacker News 의견

• 이건 단순한 취약점 하나가 아니라 여러 보안 실패의 집합임
  예를 들어, 지원자 서류를 목적 달성 후에도 실서버에 계속 두는 건 전혀 필요 없는 일임
  이런 건 blast radius(피해 범위) 최소화 원칙에도 어긋남
  이런 상황이면 평생 무료 티켓이라도 받아야 할 정도임

  • 규칙 1: 사용자 입력 데이터는 절대 신뢰하지 말 것
    이 규칙이 깨지는 순간, 다른 모든 규칙이 무너지는 건 시간문제임

• Ian, 웹사이트에 RSS 피드를 추가하면 정기 구독자가 더 늘 것 같음

  • Ian은 정말 글을 잘 쓰는 사람임
  • 나도 이 의견에 동의함

• 제보 당일에 바로 사이트를 오프라인으로 내린 것이 놀라움
  이런 대응 속도는 보기 드문 일임

  • 맞음, 수정도 꽤 빨랐음
    이런 규모의 기업이 이렇게 빠르게 움직이는 건 드문 일임

• 이건 정말 부끄러울 정도로 형편없는 보안 수준임

  • 이걸 보안이라고 부르기도 민망함, 그냥 완전히 열려 있었음
    그래도 이런 걸 보면 내 임포스터 증후군이 좀 완화되는 느낌임
  • 파티 영상까지 보면 더 놀랄 걸

• 이런 상황이면 작성자들에게 F1 슈퍼 라이선스라도 줘서 직접 차를 몰게 했으면 좋았을 텐데 하는 아쉬움이 있음

  • 그게 다였으면 얼마나 좋았을까 하는 생각임

• 혹시 이런 식의 보안 탐색을 하다가 법적 위협을 받은 적이 있는지 궁금함
  버그 바운티 프로그램이 없는 곳에서도 보상 제안을 받은 적이 있는지도 궁금함

  • 이런 행위는 법적으로 위험할 수 있음
    업계에는 실력도 없고 책임감도 없는 사람들이 많음
    이런 사람들에게는 보안 제보가 곧 ‘귀찮은 일거리’가 되기 때문에, 책임 회피를 위해 제보자를 탓하거나 법적 조치를 취하려는 유인이 생김
    그래서 익명으로 활동하는 게 가장 안전함. 나중에 원하면 신원을 공개할 수도 있음
  • 독일의 “Modern Solution” 사건이 대표적임
    한 IT 엔지니어가 비밀번호를 발견하고 phpMyAdmin 접근 가능성을 보고했는데, 회사가 그를 고소했고, 최고법원까지 가서 회사가 승소함
    관련 기사 (Heise)
  • 블로그에서 설명된 것처럼 관리자 권한 상승 시도는 법적으로 애매함
    이런 건 보통 공식적인 레드팀 테스트나 침투 테스트 계약 하에서만 허용됨
    사후에 “윤리적이었다”고 주장하는 건 충분하지 않음
  • 실제 법적 위협은 드물지만, 일부 회사는 ‘소급 버그 바운티’ 라는 명목으로 뇌물을 제안하기도 함
    이런 제안은 반드시 거절해야 함
  • 대학 시절 취약점을 제보했을 때 회사가 법적 위협을 했지만, 교수님이 강하게 항의하자 철회했음
    이후 8년간 그런 일은 없었음
    요즘은 예전보다 기업들이 이런 활동을 더 이해하는 분위기임

• 내가 제일 좋아하는 해킹 방식은 JS 읽고 PUT 요청 수정하기임
  생각보다 자주 통함

• 낡은 회사는 낡은 보안을 가짐
  RD는 잘했지만 전혀 놀랍지 않음
  해시가 아마 MD5일 거라고 거의 확신함

  • 어떤 해시 알고리즘을 쓰는지 궁금함
  • F1 사이트라면 “move fast and break things”가 딱 어울림
    xkcd 1428을 떠올리게 함

• 이상한 점은, 사이트 운영자는 Ian Carroll인데 예시에는 유명한 버그 바운티 헌터 Sam Curry가 등장함

  • 게시글에 따르면, Gal Nagli, Sam Curry, Ian이 함께 F1 관련 사이트들을 해킹해보기로 했다고 함
  • Ian의 다른 글들을 보면 이들이 자주 협업하는 걸 볼 수 있음