재일 처음 발견한 버그가 로그아웃 부분의 버그였는데

이를 proc으로 변형한 주소에서 액션을 막아버리는 보안 패치를 해준것으로 알고 있습니다.

하지만, 다들 몇몇분들은 아시다 시피 disp액션에 대한 보안실행 부분도 어느정도 진행 해줘야 할 것 같다는 생각이 들어요.

 

보통 disp에서는 DB를 Get(가져오기)액션을 취하는 경우가 많기 때문에 문제없지만, 일부 명령ACT을 취하는 경우가 있죠..

 

대표적인 예로 로그아웃의 명령이 disp명령으로 이루어져있죠..

 

이러한 액션들을 모두 proc액션으로 돌려야 하지 않을까 생각되는데.. 다른분들은 어떻게 생각하시는지 모르겟내요..

 

 

람보

profile
람보입니다.
  • ?
    안 막혔을거에요 ㅎㅎ 로그아웃은 사실 그렇게 치명적이진 않죠.. 귀찮게 할 뿐..
    제 애드온을 쓰시면 필터링은 확실히 됩니다.
  • ? profile
    아항. 그래도 귀찮은 부분이 있어도 외부글의 의한 정보가 바뀌는 문제점이기도 하기 때문에 어느정도 명령메소드가 바껴야 한다고는 생각되어서요 ㅎ
  • profile ?
    동작이니 proc 가 의미상 더 맞는거 같긴 해요
  • profile
    근데 막을 수 있나요?
    로그아웃의 경우 링크로 구현된 경우가 대부분이라
    그렇게되면 로그아웃은 무조건 post로 구현해야 하는 거 아닐까요?
  • profile profile
    새로 개발하는 레이아웃이나 회원정보 위젯이라면 form을 사용해서 POST 방식으로 구현할 수 있겠죠. 로그아웃 링크를 클릭하면 form이 제출되도록... 아니면 AJAX로 구현해도 되고요. 물론 기존의 레이아웃과 회원정보 위젯 스킨은 모두 쓰레기통으로 ㅠㅠ
  • profile profile
    네 애초에 제대로 된 매뉴얼도 없지만,

    이미 사실상 매뉴얼시 되는 방식을 변경하려면 사전협의 과정이 필요하니까요..ㅠㅠ

    차라리 로그아웃 쪽에 인증키를 넣어서 인증키가 다를 경우 리턴 시키는 게 더 바람직하지 않을까 합니다.
  • profile
    하지만 모든 레이아웃에 dispMemberLogout 으로 사용되고 있어서 바꿔버리면...;;;
  • profile profile
    어느정도 메뉴얼은 제시해주시거나.. dispMemberLogout을 실행시켰을때 코드 사용을 어디서 실행되었는지.. 등의 검사를 해준다면요..(미솔님의 애드온처럼요..)