[3주차 코칭] 이제 진짜 해킹 시작!

3주차 리뷰

1. 세션 : 웹서버와 내가 어떻게 기억하고 있을지, 식별/인증/유지
2. 세션 ID 값은 예측이 불가능해야하고 위조가 가능하면 안됨
3. 쿠키 : 클라이언트측에 저장되는 정보, 웹 서보로 보내는 웹 패킷 + 데이터 쪼가리
4. 세션 : 웹 서버에 저장되는 정보

 

Q&A

1. if (password_verify($row['user_password'], $hash_post))
if (password_verify($userpassword, $hash_db))
이렇게 password hash 비교하는 값을 반대 방식으로 해도 결과값이 똑같이 나오는데
데이터베이스 변수를 앞에다 넣고 post 변수 해쉬값을 뒤에다 넣어도 괜찮나요?

2. 로그인로직이 부루트포스방지 땜에 5회제한을 둔다거나 prepare문을 쓴다거나 이런것도 다 로직중 하나라고 보는건가요?

3. 해시 알고리즘 종류가 여러가지 있던데 실제로 특정 상황에 따라 다르게 사용 하는건가요?

4. 과제에서 로그인17개에서 개행은 파라미터가 개행되는건가요? 예를 들어서 select * from user_info where user_id =':id' and pass = ':pass\n' 이런식으로여

5. 1-3 식별/인증동시+해쉬
이부분이 막히는대.

 password_hash로 해싱하면 매번 값이 바뀌는대
db에서 값을 비번을 가져올때
처음에한 해싱과 로그인시 한 해싱이 달라져서 해당 라인을 가져오는게 안될꺼 같습니다.
그래서 이전기수분들 내용 찾아보니 고정값을 가지는 md5 혹은 sha로 작업 하신거 같더군요

제가 이해한건 기본값은 bycryte  알고리즘에서는 동시인증+해쉬는 불가능 하다  인대 맞는건가요?

6. 로그인 인증/식별(with hash)방식에 솔트 값을 추가하면 어떻게하든 db에서 salt값을 가지고 와야해서 식별/인증 동시에 안되더라구요! 이렇게 이해하면 될까요?

7. 세션id가 브라우저당 하나씩 발급되는거 맞죠? 로그인id당 하나가 아니라요,, 탭과 창 시크릿창이 열릴때마다 세션id가 유지가 되거나 공유가 되거나 생성이 되는 구조가 궁금했어요. 세션id는 브라우저당 하나씩 발급이 되면 was서버에 저장된 세션저장소(?)에도 그 세션id의 연관배열(?)이 사실은 그리 부하가 되지 않을 것 같다는 생각이 드는데, jwt의 방법이 왜 필요했을까 궁금했어요. 물론 세션공간으로 들어가 키값으로들어가 다시 그 배열을 찾는 불편함이 있겠지만요..
+추가로 식별/인증 분리후 해시처리하는 방법은 로그인처리가 안되는게 맞을까요?

8. 아직 세션과 쿠키에 무슨 값들이 들어가는지 잘 모르겠는데, 제가 이해한건 세션은 민감한 정보, 쿠키는 누구나 알아도 되는 정보 (말씀하신 것 처럼 포스팃에 적어서 봐도 되는...?) 를 담아두는 것 맞나요??

9. 혹시 만약 구글 쿠키가 탈취 당하면 구글로 로그인 지원하는 사이트에서 로그인 가능할까요?

10. bycript 방식처럼 salt값을 별도로 저장하지 않고 암호화 방식에 맡겼을 때도 평문을 얻거나 평문이 아니더라도 인증을 진행시킬 수 있나요?
bcrypt 방식이요!

11. 식별인증을 합친것과 분리하는 것은 어떤 기준에서 나눠 만드는건가요? 만들다보니 굳이 나누거나 합쳐야한다의 판단기준이 궁금했네요.

 

4주차 코칭

1. BurfSuite : 웹 프록시 툴 사용 예정
2. ctf.segfaulthub.com 활용 예정