wonder

☞ 모바일 앱 해킹 vs 단말기 해킹 단말기서버. 모바일 앱해킹 중 웹 서버측 취약점은 그냥 웹에서 하던것처럼 burp같은 프록시를 연결해서 웹에서와 마찬가지로 파일 업로드나 그런 취약점들을 찾으면 되는 거라 크게 문제가 되지 않습니다. 하지만 여기서 한가지 문제가 있다면 앱서버와 단말기 사이의 통신이 HTTPS일 경우 입니다. 단말기 burp(프록시) 앱서버 원래는 burp같은 프록시는 open browser 이런 게 안되고 그냥 setting에 들어가서 proxy 리슨상태로 만든 뒤 웹 브라우저에서 따로 connection을 했어야되었습니다. 그게 정석입니다. 여기에 하나더 설정해서 서로 HTTPS 사용할 수 있도록 단말기에 burp 인증서를 설치해야 합니다. 검색하면 나옵니다. 인증서를 설치하면 평..

☞ XXE(XML External Entity) Injection 즉 XML 외부 객체 인젝션입니다. XML(extensible markup language)는 이름과같이 html같은 마크업 언어에서 확장된 버전입니다. 만들어진 초기에 데이터를 체계적으로 주고받기 위해서 개발했습니다. 데이터의 관리 즉 데이터베이스 처럼 활용할 수 있는 것입니다. 학생들의 정보를 관리할 때의 형식은 트리구조입니다. 이런식으로 되어있구요. 각 마크업 태그 하나가 XML Entity(객체) 입니다. 처음에 나왔을 때는 주고받기가 너무 좋았습니다. 원래는 POST방식으로 바디부분에 id=wonder&pass=1234 로 되던 것을 XML형식으로도 관리가능합니다. SQL injection을 할 때는 원래했던방식과 비슷하게 id에..

☞ 기존 공격 정의 및 개념 정리 CSRF 무엇인가(what) CSRF는 직역하면 사용자의 요청을 위조하는 공격입니다. =사용자가 자기도 모르게 서버로 임의의 요청을 보내게 만드는 공격입니다. 어디에서 발생하나(where?) 서버로 보내는 모든 요청(요청 패킷 내에 이용자 검증이 없는곳) -- XSS가 되는곳 stored로 스크립트를 사용자가 받기 때문에 파라미터 값에다가 넣을 수도 있고. XSS가 통하는 모든 곳 그리고 XSS가 안되도 get방식으로도 주소를 만들어서 될 수 있음. 왜 발생하나(why?) 공격자가 서버로 보내는 임의의 요청 위조할 수 있기 때문입니다.(예를들어 요청정보를 예측할 수 있기 때문에) 예를들어 이용자 인증정보나 랜덤한 토큰 정보가 없는 요청을 말합니다. --- 사용자의 요청을..

what? 무엇인지 where? 어디에서 발생하는지 why? 왜 발생하는지 scenario 뭘할 수 있는지 defence 어떻게 대응해야하는지 각각의 취약점에 대해 생각해보며 한마디로 정리할 수 있어야합니다. ☞ 시나리오 복습 및 상세 연구 SQLi 시나리오 1) DB 데이터 추출가능 2) DB 데이터 변조가능 3) DB 데이터를 이용한 인증/인가 우회가능 4) 웹쉘 업로드가능 into outfile를 이용하여 DB서버에 파일을 업로드할 수 있습니다. 하지만 전제 조건은 DB서버와 웹서버가 안전하게 분리되어 있지 않고 하나로 통합되어 있을 경우에만 웹서버 경로에 웹쉘 업로드를 하여 실행시키는 의미가 있습니다. 5) 파일 다운로드 load_file() 함수를 이용하여 파일을 다운받아 소스코드 확인 등 공격..

☞ 기존 보고서 피드백 및 수정 최대한 볼드 체를 쓰지 않고 알록달록하게 하는 게 아니라, 그리고 폰트 크기도 최대한 10으로 맞추되 정말 강조해야할 부분이나, 목차같은 부분에서만 bold와 12, 11 정도의 폰트 크기를 사용합니다. SQLi 같은 경우에는 union 방식 등 중복되는 방식이 많습니다. 이럴 경우 정말 대표적인 예시만 작성하고 중복되는 걸 적지 않습니다. 또한 모든 자세한 기술적인 내용, STEP을 개발자가 알 필요가 없습니다. 증명만 하면됩니다. Step 1. 회원가입 페이지에 접속 및 글 작성 페이지 이동 Step 2. database명을 알아내는 SQL문 삽입 Step 3. ~~ 파라미터에 UNION문 삽입으로 DB명을 추출 하는 것을 확인. --- 만약 일반적인 데이터 추출이아니..

HTTPS(SSL)은 무조건 인증서를 받아야 사용할 수 있습니다. 하지만 그렇다고 해서 다 안전한 사이트가 아닙니다. CA에게 공인 인증서를 받아야하는데 자체적으로 제작한 사설 인증서를 받거나 신뢰할 수 없는 CA 기관이라면 여전히 안전하지 않은 사이트로 뜹니다. ☞ HTTPS(SSL) 의 암호화 방식 = 대칭키 + 비대칭키 방식의 혼용 통신 과정 및 개념이 복잡하지만 확실한 것은 서버 인증서 교환하고 신뢰 기관인지 여부를 확인할 때는 비대칭키(공개키) 방식을 사용하지만 그 이후로는 서로 클라이언트와 서버가 데이터를 전송할 때 대칭키 방식을 사용합니다. 서버에서 암호화 복호화 걸리는데 세션이 긴 소통방식에는 좋은 방식이 아닙니다. 따라서 대칭키 방식 사용은 https를 써도 속도가 원활한 이유입니다. 대..