SQL 삽입을 방지하기 위해 사용자 데이터의 일부를 파일에 저장합니다.

Question

저는 웹 프로그래밍에 익숙하지 않고 웹 보안과 관련된 문제를 탐구 해 왔습니다.

사용자가 두 가지 유형의 데이터를 게시 할 수있는 양식이 있습니다. SQL의 관점에서 보았을 때 "안전한"또는 "안전하지 않은"호출이 가능합니다.

대부분의 경우 "안전하지 않은"부분을 소독 한 후 데이터베이스에 데이터의 두 부분을 모두 저장하는 것이 좋습니다 ("안전"하도록).

"안전한"데이터를 데이터베이스에 저장하고 "안전하지 않은"데이터를 파일 (데이터베이스 외부)에 저장하는 방법에 대해 궁금합니다. 물론이 접근법은 파일과 DB 항목 간의 연관성 유지와 관련된 자체 문제 집합을 만듭니다. 그러나이 접근법에서 특히 보안과 관련된 다른 주요 문제가 있습니까?

업데이트 : 응답 해 주셔서 감사합니다! 내가 무엇인지에 관해 명확하지 않은 것에 대해 사과한다 "안전한"것을 고려하고있는 약간의 설명이 순서에있다. 나는 장고를 사용하고 있으며, "안전"을 고려하고있는 데이터는 필요한 모든 탈출을 수행하는 양식의 "cleaned_data" 사전을 통해 액세스됩니다.

이 질문의 목적을 위해 우리는 위키 페이지를 고려해 보겠습니다. 위키 페이지의 제목에는 어떤 스타일링도 첨부 할 필요가 없습니다. 따라서 양식의 "cleaned_data"사전을 통해 에 액세스하여 사용자 입력을 "안전한"형식으로 변환합니다. 그러나 사용자가 임의로 콘텐츠를 의 스타일로 꾸밀 수 있기를 원하기 때문에 "cleaned_data"사전을 사용하여 콘텐츠 부분에 액세스 할 수 없습니다.

파일 접근 방식이이 문제의 보안 측면을 해결합니까? 아니면 내가 간과하고있는 다른 보안 문제가 있습니까?

Answer 1

"안전하고"안전하지 않은 것으로 생각되는 항목은 무엇입니까? 슬래시가 이스케이프 된 데이터를 "안전"하다고 생각하십니까? 그렇다면,하지 마십시오.

SQL 플레이스 홀더에서 바운드 변수를 사용하십시오. SQL 인젝션을 방지하는 유일한 방법입니다.

Answer 2

데이터를 분할해도 SQL 삽입으로부터 보호 할 수는 없지만 공격을 통해 노출 될 수있는 데이터는 제한되지만 공격의 유일한 위험은 아닙니다. 또한 데이터를 삭제하고 가짜 데이터를 추가 할 수 있습니다.

특히 준비된 문을 사용하는 경우 (모든 개발 플랫폼과 데이터베이스가 아닌, 많은 경우 지원됨) 사용자의 접근 방식을 사용하는 것은 정당화되지 않습니다.

악몽에 빠져들지 않고도 접근 방식이 끝나게됩니다.

결국 신뢰할 수 없다면 왜 데이터베이스를 사용할 것입니까? 원하는 경우 일반 파일 만 사용하십시오. 믹스는 아니요입니다.

Answer 3

SQL 주입은 사용자뿐만 아니라 쿼리 대상 (중독 쿼리)이기 때문에 SQL 삽입 공격을 피하는 가장 좋은 방법은 쿼리를 제어하고 보호하는 것입니다 저장 장치를 분할하는 것보다는 악의적 인 문자가 주입 될 가능성이 있습니다.

Answer 4

당신이 말하는 "안전한"데이터를 알고 있습니까? 그렇지 않습니다.모두이 안전하지 않으므로이를 취급해야합니다. 파일에 알을 저장하는 것이 아니라 SQL 문을 올바르게 구성하는 방법.

다른 사람들이 언급 한 것처럼 준비된 명령문이나이를 시뮬레이트하는 라이브러리를 사용하여 이동하는 방법이 있습니다.

$db->Execute("insert into foo(x,y,z) values (?,?,?)", array($one, $two, $three));