php 기본 보안은 EGPCS (Environment, Get, Post, Cookie, and Server) 내에서 이루어짐.. JSP 는 모르겠음.
ㅇㄱㄹㅇㅂㅂㅂㄱ(121.164)2014-11-28 15:09
ㄴ 뭐 웹 관련은 거의 위의 항목은 마찬가지징 ㅇㅇ
☎2.56™(roidz)2014-11-28 15:10
GET은 중요 데이터는 암호화 해서 주고 받는 이슈가 있을꺼고 암호화 하면 응답속도 품질 이슈도 생기고, Post는 SSL 적용하냐 안하냐 이슈 생기고, GET, POST 모두 DB랑 붙으면 SQL 인젝션 이슈가 생기고, 그것 아니라도 인자에서 서비스에 영향 줄 수 있는 부분에 대한 이슈가 있겠징
☎2.56™(roidz)2014-11-28 15:12
세션은 세션되로 보안 이슈가 있고, 기록을 다 남겨야 하는 상황이라면 로그 및 접근 추척 이슈도 생기고, 백이나 리프레쉬 통한 GET 2번 연속이나 POST 2번 되는 것 방지 이슈도 있고, 쿠키는 사용자 PC에 저장되는 것이라서 그에 따른 이슈가 있고, 그런점에서 자바스크립트 보안 이슈도 생기고..
☎2.56™(roidz)2014-11-28 15:14
서버는 방화벽이나 관리자 또는 개발자 접근 이슈가 있고, 보안 때문에 발생하는 배포 문제 이슈가 있고.. 암튼 웹도 보안 이슈에 대해 마이크로 접근하면 졸라 할게 많음. 그기에 따른 사이드 이펙 때문에 새로운 일도 많이 늘어나고.
☎2.56™(roidz)2014-11-28 15:15
ㄴ 그 이외엔 일단 유저불량으로 분류함 ㅋㅋㅋㅋㅋㅋㅋㅋ 일단 유저불량의 경우도 어느정도 자동적으로 감수 해줄수 있는 솔루션들을 사람들이 찾음. 그래서 개발자들이 기본보안 가지고 골머리 안쓰게끔 이름난 MVC 프레임웤을 찾는거징 ㅎㅎㅎ 기본보안 만으로도 충분히 장난칠수 있기때문에 애초에 그런쪽은 신경쓰기 싫다 이기야. ㅎㅎㅎ
ㅇㄱㄹㅇㅂㅂㅂㄱ(121.164)2014-11-28 15:15
결론 - 웹땔감 들의 경우 EGPCS 신경 쓰기 싫고 기타 DB 인젝션 같은 공격에도 신경쓸 시간을 줄이고자 이름난 프레임웤을 쓴다 이기야 ㅎㅎ
ㅇㄱㄹㅇㅂㅂㅂㄱ(121.164)2014-11-28 15:17
그런데 종종 프로젝트 긴급 투입되어보면.. 첨에는 간단한 것만 하면 된다고 말했는데.. 까보면 프레임웍만 가져다 쓰고 그런 것들은 하나도 설계 단계에서 부터 적용 구현 되어 있지 않아서 거의 다시 재작업해야 할 것을 떠맡은 적이 몇번있다. 헬이당~ 헬~
☎2.56™(roidz)2014-11-28 15:19
이건 앱도 마찬가지인데.. 앱도 이런 것 때문에 검수 단계에서 뒷통수 제대로 맞는게 많넹 ㅠㅠ
☎2.56™(roidz)2014-11-28 15:19
ㄴ뭘하던 뒷통수 쳐맞는건 마찬가지임.. 특히나 어플을 만들었는데 웹이랑 연동되거나 할경우 이건 무슨 TEE 수준으로 보안을 계획해야 하니까 골머리 썩는거지. 그래서 업체들의 경우 사전에 일터지기 전에 L7 스위치(하드웨어링 백신처리)를 앞에 달아놓고 보안정책 때려박을거 다 때려박고 쓰는거임. 그래도 터질건 언젠가 터지지
ㅇㄱㄹㅇㅂㅂㅂㄱ(121.164)2014-11-28 15:21
ㄴ초창기가 지랄 맞았지 지금은 그렇지도 않음..
ㅇㄱㄹㅇㅂㅂㅂㄱ(121.164)2014-11-28 15:23
지금도.. 예전 소스 다시 재활용해서 사용해야 하는 곳은 그랭. 그래서 KT가 헬이라고 하는 거겠징. 그런데 KT보다 헬인 곳이 정부 관련 플젝 중에 개념없이 시작한 하도급 업체들이 그런듯. 일정만 가지고 쪼아됨
뭔데
아는되로 말해봥~
php 기본 보안은 EGPCS (Environment, Get, Post, Cookie, and Server) 내에서 이루어짐.. JSP 는 모르겠음.
ㄴ 뭐 웹 관련은 거의 위의 항목은 마찬가지징 ㅇㅇ
GET은 중요 데이터는 암호화 해서 주고 받는 이슈가 있을꺼고 암호화 하면 응답속도 품질 이슈도 생기고, Post는 SSL 적용하냐 안하냐 이슈 생기고, GET, POST 모두 DB랑 붙으면 SQL 인젝션 이슈가 생기고, 그것 아니라도 인자에서 서비스에 영향 줄 수 있는 부분에 대한 이슈가 있겠징
세션은 세션되로 보안 이슈가 있고, 기록을 다 남겨야 하는 상황이라면 로그 및 접근 추척 이슈도 생기고, 백이나 리프레쉬 통한 GET 2번 연속이나 POST 2번 되는 것 방지 이슈도 있고, 쿠키는 사용자 PC에 저장되는 것이라서 그에 따른 이슈가 있고, 그런점에서 자바스크립트 보안 이슈도 생기고..
서버는 방화벽이나 관리자 또는 개발자 접근 이슈가 있고, 보안 때문에 발생하는 배포 문제 이슈가 있고.. 암튼 웹도 보안 이슈에 대해 마이크로 접근하면 졸라 할게 많음. 그기에 따른 사이드 이펙 때문에 새로운 일도 많이 늘어나고.
ㄴ 그 이외엔 일단 유저불량으로 분류함 ㅋㅋㅋㅋㅋㅋㅋㅋ 일단 유저불량의 경우도 어느정도 자동적으로 감수 해줄수 있는 솔루션들을 사람들이 찾음. 그래서 개발자들이 기본보안 가지고 골머리 안쓰게끔 이름난 MVC 프레임웤을 찾는거징 ㅎㅎㅎ 기본보안 만으로도 충분히 장난칠수 있기때문에 애초에 그런쪽은 신경쓰기 싫다 이기야. ㅎㅎㅎ
결론 - 웹땔감 들의 경우 EGPCS 신경 쓰기 싫고 기타 DB 인젝션 같은 공격에도 신경쓸 시간을 줄이고자 이름난 프레임웤을 쓴다 이기야 ㅎㅎ
그런데 종종 프로젝트 긴급 투입되어보면.. 첨에는 간단한 것만 하면 된다고 말했는데.. 까보면 프레임웍만 가져다 쓰고 그런 것들은 하나도 설계 단계에서 부터 적용 구현 되어 있지 않아서 거의 다시 재작업해야 할 것을 떠맡은 적이 몇번있다. 헬이당~ 헬~
이건 앱도 마찬가지인데.. 앱도 이런 것 때문에 검수 단계에서 뒷통수 제대로 맞는게 많넹 ㅠㅠ
ㄴ뭘하던 뒷통수 쳐맞는건 마찬가지임.. 특히나 어플을 만들었는데 웹이랑 연동되거나 할경우 이건 무슨 TEE 수준으로 보안을 계획해야 하니까 골머리 썩는거지. 그래서 업체들의 경우 사전에 일터지기 전에 L7 스위치(하드웨어링 백신처리)를 앞에 달아놓고 보안정책 때려박을거 다 때려박고 쓰는거임. 그래도 터질건 언젠가 터지지
ㄴ초창기가 지랄 맞았지 지금은 그렇지도 않음..
지금도.. 예전 소스 다시 재활용해서 사용해야 하는 곳은 그랭. 그래서 KT가 헬이라고 하는 거겠징. 그런데 KT보다 헬인 곳이 정부 관련 플젝 중에 개념없이 시작한 하도급 업체들이 그런듯. 일정만 가지고 쪼아됨
ㄴ 개티브엑스 쓰는곳을 좀 줄어들었드만..
대신 게티브액스를 크롬에서도 돌아가도록 바꿔야하는 것도 막 튀어나옴. 막바지쯤에 ㅋㅋㅋ
ㄴ 올앳페이 극혐.
ㄴ 무대뽀 가능한 곳은 kt랑 기브 앤 테이크가 있는 쌍용뿐 ㅇㅇ