SQL 주입에 대한 보호가 우선 순위가 아닌 이유는 무엇입니까?


39

스택 오버플로에서 10 가지가 넘는 기본 해결 방법이 널리 보급되어 있음에도 불구하고 SQL 주입 공격에 매우 취약한 MySQL 쿼리가있는 질문과 답변에 많은 PHP 코드가 있습니다.

이러한 유형의 코드 스 니펫이 오늘날에도 여전히 사용되는 이유가 있습니까?


37
잘못 작성된 온라인 자습서를 비난하십시오. 종종 사람들은 인터넷에서 찾은 코드를 복사하여 붙여 넣기 만하면됩니다. JavaScript는 또한 그러한 관행의 또 다른 희생자입니다.
KJYe. Name

34
블로그를 비난하십시오. 아, 그리고 W3Schools…
Brian Driscoll

13
예, 절대적으로 W3 스쿨 - 볼 w3fools.com
DisgruntledGoat

2
나는 사람들이 SQL 주입에 대해 경고하는 것을 끊임없이 보았습니다. 그래서이 질문의 전제가 타당하다고 생각조차하지 않습니다. 그것은 이다 높은 우선 순위.
GrandmasterB

3
내가 많은 답변에서보고있는 것은, 심각하게 깨지지 않은 PHP를 가르치는 것보다 심각하게 깨진 PHP를 가르치는 것이 더 쉽다는 것입니다. 당신은 그 주장에 동의하고 아직 PHP 나쁜 언어 아니라고 주장 할 수 없습니다
user16764가

답변:


34

나는 주로 a) 무지 b) 게으름 때문이라고 생각합니다. 초보자는 일반적으로 SQL 삽입에 대해 많이 알지 못하며 그것에 대해 들었을 때조차도 그렇게 간단하고 코딩하기가 쉽기 때문에 무시합니다.


8
나는 다른 곳에서 그러한 문제를 해결하려고 노력했지만 현재 문제와 관련이 없다고 들었습니다. 따라서 많은 사람들이 약간 더 복잡한 좋은 솔루션에 대한 간단한 해킹을 선호하기 때문에 나쁜 예는 혼자 남아 있습니다.
l0b0

6
대부분의 사람들은 SQL 인젝션이 나올 때까지 SQL 인젝션에 관심이 없습니다. 그런 다음 갑자기 테이블이 어디로 갔는지 궁금합니다.
Joel Etherton

1
다른 이유는 SQL 인젝션이 항상 내부 앱의 관련 관심사로 간주되는 것은 아닙니다. (그들이 옳은 것은 아닙니다.)
John Fisher

1
질문에 대답하기 위해 답변이 있다는 것을 잊지 마십시오. 종종 안전하고 안전한 복사 및 붙여 넣기 솔루션을 제공 할 필요는 없지만 질문에 대답하기위한 의사 코드 (또는 SQL)가 있습니다 (응답이 실제로 어떻게 사용되는지에도 불구하고).
Dalin Seivewright

1
@ l0b0 나는 현재 프로덕션 코드에 대한 SQL 인젝션 공격을 실제로 보여줌으로써 SQL 인젝션 픽스를 진지하게 받아들이는 사람을 알고 있습니다.
user16764

26

PHP는 알고있는 사용자가 유용한 동적 웹 페이지를 거의 만들지 못하도록 의도적으로 정말 쉽게 만듭니다. 즉, PHP는 유용한 무언가를 만들고 다른 유용한 예제를 통해 배우고 다른 사람들에게이 멋지고 유용한 것을 수행하는 방법을 가르치는 초보자를 많이 끌어들일 것입니다. 결과적으로 많은 잘못된 코드와 더 잘 모르는 프로그래머가 제공됩니다.

유능한 프로그래머 중 상당수가 PHP와는 아무 관련이 없다는 것이 문제를 악화시킵니다. 이것은 다른 사람들을 더 잘 가르치고 자하는 숙련 된 사람들의 기초를 줄입니다. 그러나 왜 PHP를 피합니까? 요인의 조합에 적합합니다. 부분적으로 그들은 언어 사마귀를 다루는 것을 좋아하지 않습니다. 그리고 부분적으로 좋은 코드로 작업하는 것을 선호하기 때문에 좋은 PHP가 많지 않습니다.

Perl에 영향을 미치는 데 사용되는 문제의 정확한 별자리. 빛나는 사례로서 1990 년대에 유용하고 잘 문서화되어 있고 설치하기 쉬운 CGI 스크립트를 많이 제공하기 위해 열광적 인 십대 인 Matt Wright의 사례를 고려하십시오. 불행히도 그는 보안에 대해 전혀 이해하지 못했으며 자신의 물건을 사용하려는 사람들도 없었습니다. 결과는 Matt Wright Script Archives로 초기 CGI 스크립트의 끝없는 보안 문제였습니다. http://www.scriptarchive.com/nms.html 과 같은 노력에도 불구하고 공유 호스팅 공급자가 PHP를 다른 것보다 편리하게 만들 때까지 Perl의 문제는 개선되지 않았습니다. 이로 인해 Perl에서 PHP로 이동하는 데 문제가 발생합니다.


당신이 말했듯이, 문제는 펄이나 PHP가 아닙니다.이 언어는 초보자가 많은 일을 할 수있게 해주지 만 항상 좋은 방법을 항상 제공하지는 않습니다.
Zachary K

2
@ZacharyK : 기본적으로 언어 오류가 아닌가?
Monica

6
@ tomalak-geretkal : "결함"이라는 단어를 사용하면 작업을 수행 할 수있게 만드는 것이 나쁜 것 같습니다. 많은 불량 코드로 이어지는 동일한 특성으로 인해 많은 실제 문제가 해결됩니다. 이것이 전체적으로 나쁜 것임을 분명하지 않습니다.
btilly

다시 '결함': HTML (또는 HTML을 해석하는 브라우저)이 XSL처럼 내결함성이 있다면 월드 와이드 웹은 없었을 것입니다 ...
Benjol

8

불행하게도 거기 이 더 많은보다 나쁜 PHP 자습서는 일부 오래된 PHP 책은 또한 (등 register_globals를 사용 안 함) 적절한 코드를 작성하는 사람들에게 이야기에 빨려 들었어.

또한 magic_quotes_gpc과거에 활성화 된 사람들은 "간단히 작동"했기 때문에 탈출에 신경 쓰지 않았습니다.



2

인간이자 프로그래머 인 저는 실수를 저지르는 것이 매우 쉽고, 특히 시간이 촉박 할 때 특정 일을 간과합니다.

특정 언어를 비난하고 자신의 이익을 위해 너무 접근하기 쉽다는 것은 쉽고 어쩌면 너무 유혹적입니다. 그러나 그것은 프로그래밍을 위해 선택한 언어에 관계없이 인간의 오류 가능성에 대한 더 큰 문제에 대해 영광 스러울 것입니다.

물론 어셈블리 언어 이후로 먼 길을 갔으며 PHP, Python, Ruby 또는 Java와 같은 더 현대적인 언어로 훨씬 생산적인 프로그래밍이 될 것이라고 생각합니다.

PHP (및 기타 스크립팅 언어)는 실제로 진입 장벽을 낮췄습니다. 프로그래밍을 처음 접하는 사람들이 PHP를 먼저 시도한다는 의미 일 수 있습니다. 그러나 이것이 반드시 모든 PHP 프로그래머가 다른 언어의 프로그래머보다 자격이 떨어지거나 실수를 통해 배울 수 없다는 것을 의미하지는 않습니다.

Rasmus Lerdorf는 1994 년에 원래 형태로 PHP를 만들었으며 그 이후로 상당히 발전했습니다. 가장 현대적인 화신에서, 객체 지향 프로그래밍과 Symfony와 같은 뛰어난 프레임 워크를 지원합니다. 언어로서의 PHP는 원래의 제약 조건에서 벗어나 프로그래머가 언어를 사용하도록 선택할 수있는 유연성이 크게 향상되었습니다. 이것을 사용하여 9,000 라인의 스파게티 코드 스크립트를 만들거나 Symfony와 같은 현대적인 MVC 프레임 워크의 컨텍스트 내에서 사용할 수 있습니다.

보안 취약점이 단일 언어로 제한되지는 않을 것입니다. 모든 PHP 프로그래머에게 능력이 떨어지거나 안전하지 않은 코드를 작성하기 쉬운 경향이 있습니다. 그러나 나는 그 중 언어 편견이 얼마나되는지, 그리고 사실이 얼마나되는지 궁금합니다.


"모든 PHP 프로그래머"에 대해서는 아무 말도하지 않았습니다.
Monica와의 가벼움 경주

2

문제의 일부는 자신이하는 일을 배우지 않고 코드를 복사하는 사람들이지만 실제로는 우리가 porgamnming을 가르치는 방식이 깨져서 코드가 너무 많은 이유 중 하나라고 생각합니다. 우리는 문맥을 벗어난 구문을 가르치므로 초보자는 무언가를 사용해야 할 때와 구문이 해결해야 할 문제 또는 해결해야 할 문제 및 해결하지 않는 문제를 알 수 없습니다. 따라서 렌치가 더 좋은 도구 일 때 망치를 사용합니다.

예를 들어 구문을 가르치는 대신 다음과 같은 과정을 구성해야합니다 (물론 더 많은 단계가있을 것입니다. 구문을 가르치는 것보다 기본에서 더 복잡한 문제로 만드는 기본적인 예일뿐입니다).

  1. 기본 웹 페이지를 설정하는 방법입니다
  2. 이것은 웹 페이지를 데이터베이스에서 데이터를 가져 오는 방법입니다.
  3. 이것은 웹 페이지에서 데이터베이스로 데이터를 보내는 방법입니다
  4. 올바른 데이터가 전송되도록하는 방법입니다.
  5. 이것이 악성 데이터 입력으로부터 데이터베이스를 보호하는 방법입니다

그것은 내가 어느 정도 가르치는 방식이다 PHP +1
Rémi

1

비슷한 수준의 MS SQL + ASP / ASP.NET 예제도 마찬가지로 취약하다고 생각합니다.

문제는 WHERE 절을 사용하여 데이터를 필터링하는 것과 같이 무언가를 가르치려고 할 때 쿼리 문자열을 올바르게 이스케이프 처리하거나 매개 변수가 지정된 명령을 사용하여 예제를 어지럽히고 싶지 않다는 사실에서 부분적으로 발생한다고 생각합니다.

저는 수년간 개발자를 훈련시켜 왔으며 튜토리얼에서 끔찍한 코드를 작성하는 사람들과 공감할 수 있습니다. 때때로 그것은 가장 쉽게 이해됩니다. 그러나 제쳐두고 나는 항상 취약한 코드를 지적하고 흥미로운 부 주제로 만듭니다.


6
그것은 제쳐두고해서는 안됩니다. 그것은 기본 수업의 일부 여야합니다. 아마도 일을 잘못하는 방법에 대해 경고하는 크고 뚱뚱한. 사람들은 처음 보는 것을 자르고 붙여 넣는 경향이 있으며, 실제로 올바른 일을하기를 원합니다.
btilly

확실히 .NET 세계에서 매개 변수화는 요즘 꽤 간단하며 실제로 '한 페이지'항목이어야합니다.
Alan B

1

PHP의 원저자 인 Rasmus Lerdorf 는 그의 유명한 블로그에 "프레임 워크없는" 개발을 옹호 합니다. SQL 쿼리의 경우 PDO를 사용하지만 SQL 삽입의 위험이 없습니다. ORM 레이어가있는 최신 MVC 프레임 워크와 비교할 때 여전히 추악하고 쓸모가 없습니다.


5
복잡한 프레임 워크를 사용하여 필요하지 않은 사이트를 과도하게 엔지니어링 할 수 있습니다. 나는 라스무스의 제안이 범죄 적으로 위험에 처해 있다고 말하고 있지만, 분명히 중간 정도의 근거가 있습니다.
Monica

오늘날 ORM을 사용하는 것은 과도하게 엔지니어링되지 않습니다. 표준입니다. MVC 패턴을 사용하고 있습니다.
vartec

3
@vartec : 모든 양 (그것의 가치도없는 것에 대해, 그리고 그것을 사용해서 그것은 거의 "표준"의 모든 양이 되어 그것을 사용). 작은 스크립트의 경우 쉽게 과도하게 엔지니어링 할 있습니다.
0:40에 Monica

1
@Tomalak : 깨끗하고 지속 가능한 프로젝트를 구현하는 방법이기 때문에 표준입니다. "작은 대본"은 시간이 지남에 따라 커져서 유지 불가능한 괴물로 변하는 경향이 있습니다.
vartec

2
@vartec : "표준"의 의미를 잘못 이해했다고 생각합니다.
Monica와의 가벼움 경주

1

PHP 자체에서이 잘못된 연습을 비난 할 수 있습니다. 레거시 버전의 PHP (2006 년 경까지)는 데이터베이스 쿼리 보간 BY DEFAULT에 적합하도록 모든 GET 및 POST 입력 변수를 이스케이프합니다. http://php.net/manual/en/security.magicquotes.php를 참조 하십시오


2
그들은, 특히 MySQL의에가는 것처럼이 모든 변수를 탈출 할 시간이 있었다 그들도했다 여부는 . 언어 디자이너에 대한 참고 사항 : 구현 stripslashes()해야 할 것을 이미 발견했을 때 이미 잘못했습니다.
Dan Ray

0

튜토리얼의 목적을 혼동하지 마십시오. 이는 프로덕션 환경에서 수행해야하는 것과 간단하게 무언가를 설명하는 것입니다. 예를 들어, 내가 작성한 대부분의 자습서 코드에는 오류 / 예외 검사가 거의 또는 전혀 없습니다. 독자에게 코드는 가능한 모든 결과를 다루는 방법이 아니라 특정 작업을 수행하는 방법 만 보여줍니다.


3
죄송하지만 예제 코드는 PHP와 mySQL 쿼리를 혼합해서는 안됩니다. 그것은 단순히 잘못하고 있습니다.
Raynos

1
그리고 무책임한.
Monica와의 가벼움 경주

의 경우 -1입니다 most tutorial code I have written has little or no error/exception checking..
yannis

OP의 요점을 볼 수 있습니다. 무책임한 것은 고용주가 SQL 인젝션 등에 대한 지식이 부족한 사람을 고용 할 때입니다.
Raffael

"제작에 이것을 사용하지 마십시오!"라는 코드에 직접 주석을 포함하면이 방법이 방어 적이라고 생각합니다. 그렇게하면 복사 / 붙여 넣기에 대한 변명이 없습니다.
Benjol

-1

내가 PHP를 배우고있을 때 나는이 PHP + MySQL 서적을 보았는데, 그 나쁜 연습에 기여한다고 생각합니다. 그러나 나는 좋은 프로그래밍 관행이 아니라 언어를 가르치고 있기 때문에 동정심을 가지고 있습니다. 그렇지 않으면 어디에서 끝나겠습니까?


2
그러나 언어를 가르 칠 때 여전히 예제에서 선호하는 API를 사용해야합니다. 파라 메트릭 형식의 SQL 쿼리를 항상 사용하는 것처럼 "보간을 사용하여 SQL을 작성하는 것을 생각하지 마십시오. 조금 더 쉬워 보이지만 보안 취약점이 발생하기 쉽습니다."
Jan Hudec

네, 좋은 지적입니다. 각주는 좋은 알림이 될 것이며 온라인 자습서에서도 마찬가지입니다. 그러나 모든 언어의 저술가가 OWASP의 조언을 초급 텍스트에 포함시킬 수 있다면 정말 좋을 것입니다. 참조로도. OWASP 재단은 훌륭한 일을합니다.
Steve Rathbone

@indifferentDrum : 사람들이 발로 운전하도록 가르 칠 수 있습니다. 좋은 생각이 아닙니다.
Monica와의 가벼움 경주
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.