대부분의 DB Injection의 목적은 해킹을 위한 코드의 삽입이 목적 입니다.
바이러스 프로그램만 튼튼하게 설치하면 대부분 문제 없구요
패스워드는 암호화 되어 있기 때문에, 귀챦아서 cracking 안합니다 (더 쉬운 해킹 방법이 많으니까요)
DB Injection의 경우 뭔 짓을 했는지 로그체크가 좀 난합니다 (MySQL의 경우에는...)
2CPU의 경우에는 조심스럽게 필드 2개에 해킹된 사이트로 이어지는 코드를 삽입했는데 (안걸리려고)
아무런 흔적도 없는 DB Injection의 경우라면 심각하게 체크를 해야 합니다. 의도가 나쁘거든요.
저는 아예 웹방화벽에서 DROP과 DELETE를 막아두는 쪽으로 세팅합니다.
DROP은 거의 문제가 안생기는데, DELETE를 막으면, 소스를 좀 고쳐야 되는 데다가...DB용량이 좀 증가하는(지워야 되는걸 못지우니까..) 단점이 있습니다. 그래도 날려먹는것 보다는 나으니 적당한 시점에서 한번씩 디비를 정리해 줍니다.
Select해서 털리는건 최대한 막아보지만 안털린다는 보장이 없고... Update는 막기가 너무 어려우니 백업을 자주 하는 수 밖에요..
김황중
요새 암호는 다 기본적으로 암호화하여 저장되니 그건 그렇게 걱정하실 필요가 없을 듯 합니다.
단, 길이가 짧은 암호는 레인보우 테이블 덕에 약간 위험할 수 있습니다.
바이러스 프로그램만 튼튼하게 설치하면 대부분 문제 없구요
패스워드는 암호화 되어 있기 때문에, 귀챦아서 cracking 안합니다 (더 쉬운 해킹 방법이 많으니까요)
DB Injection의 경우 뭔 짓을 했는지 로그체크가 좀 난합니다 (MySQL의 경우에는...)
2CPU의 경우에는 조심스럽게 필드 2개에 해킹된 사이트로 이어지는 코드를 삽입했는데 (안걸리려고)
아무런 흔적도 없는 DB Injection의 경우라면 심각하게 체크를 해야 합니다. 의도가 나쁘거든요.
DB 보안수준에따라 다르겠지만 select, insert, update, delete 다 가능합니다.
delete해서 DB가 싹 다 날아가는경우와, select로 회원정보 오픈되는것이 가장 끔찍하지요.
DROP은 거의 문제가 안생기는데, DELETE를 막으면, 소스를 좀 고쳐야 되는 데다가...DB용량이 좀 증가하는(지워야 되는걸 못지우니까..) 단점이 있습니다. 그래도 날려먹는것 보다는 나으니 적당한 시점에서 한번씩 디비를 정리해 줍니다.
Select해서 털리는건 최대한 막아보지만 안털린다는 보장이 없고... Update는 막기가 너무 어려우니 백업을 자주 하는 수 밖에요..