2010-08-20 5 views
8

클라이언트 쪽 유효성 검사가 서버 쪽 유효성 검사보다 잠재적 인 보안 위험인지 또는 보안 위험인지에 대해서는 잘 모르겠습니다. 누군가가 나에게 몇 가지 시나리오를 줄 수 있습니까?클라이언트 쪽 유효성 검사가 서버 쪽 유효성 검사가 아닌 보안 위험에 노출되는 이유는 무엇입니까?

+2

유효성 검사가 클라이언트 쪽일 경우 유효성을 검사하지 않으면 클라이언트가 유효합니다. 보안이 중요하다면 클라이언트가 자신의 데이터를 검증하는 이유는 무엇입니까? – mquander

+0

중복 : http://stackoverflow.com/questions/3483514/why-client-side-validation-is-not-enough, http://stackoverflow.com/questions/1125772/should-you-do-validation-on 서버 쪽 – NullUserException

+1

클라이언트 쪽 유효성 검사는 유효성 검사가 아닙니다. UI 설탕 일뿐입니다. – seanb

답변

15

이상적으로는 클라이언트와 서버를 모두 처리 할 수 ​​있으며 둘 중 하나를 수행하지 않아도됩니다. 이 세 가지 시나리오를 살펴보면 두 가지 모두 안전하고 사용자 친화적 인 방법입니다.

클라이언트 측만 : 언급 한 바와 같이 누군가가 원하는 경우 이러한 유효성 검사를 수행하는 데 많은 시간이 걸리지 않습니다. 잘못된 형식의 데이터를 서버에 보내십시오 (예 : SQL 삽입). NoScript는 자바 스크립트 유효성 검사 코드를 실행하지 않으며 일부 브라우저는 사용자가로드 된 javascript 및 html을 변경하도록 허용하므로 사용자는 컨트롤에서 유효성 검사 javascript를 언 후크 할 수 있습니다.

서버 쪽만 :이 설정은 장거리에서 클라이언트 전용보다 안전하지만 사용자 편의성은 떨어집니다. 서버에 양식을 보내고 유효성을 검사하고 특정 필드가 잘못되었다는 오류 페이지를 다시 받아야합니다. 짜증나게하는 것은 그 필드들 중 하나가 암호 필드라면, 그 값은 기본적으로 다시 채워지지 않는다는 것입니다. 예를 들어 사용자가 계정 생성 양식에 전화 번호를 올바르게 입력하지 않았다고 가정 해 보겠습니다. 서버가 전화 번호가 틀린 방식에 대한 페이지를 다시 뱉어 내면 사용자는이를 확인하고 전화 번호를 수정 한 다음 제출을 다시 눌러 암호를 입력하지 않았다는 다른 오류 페이지를 수신합니다 (두 번째로 다시 입력). 텍스트 상자) 초기 문제는 아니지만.

클라이언트 및 서버 쪽 : 서버 쪽 유효성 검사의 보안, 사용자가 누르기 어려운 작업, 페이지를 제출하지 않고도 입력 유효성 검사의 사용자 편의성을 얻습니다. 로컬 자바 스크립트 또는 AJAX).

절대적으로 하나를 선택해야한다면 서버 쪽이 최선의 방법입니다. 그러나 당신은 하나 또는 다른 것을 고를 필요가 없습니다.

+0

설명을 주셔서 감사합니다. 이제 훨씬 더 의미가 있습니다. – Xaisoft

+0

그것은 서버 측 기술을 배우기 시작했을 때 학교에서 배웠던 질문이었습니다. 그것은 사물의 큰 그림에 관한 것입니다. –

4

클라이언트 측에서만 유효성 검사를 수행하는 경우 누군가 자바 스크립트를 사용하지 못하도록 설정할 수 있습니다 (예 : 방화 광구와 함께 js 코드 변경). 따라서 js에서 이루어진 모든 유효성 검사는 쓸모 없으며 사용자는 잘못된 데이터를 시스템에 삽입 할 수 있습니다.

2

웹 시나리오에 대해 이야기하고 있다고 가정합니까?

자바 스크립트로 클라이언트 측 유효성 검사를 수행하는 경우 사용자가 자바 스크립트를 사용하지 않으면 어떻게됩니까? 그런 다음 유효성을 검증하지 않은 서버에 데이터를 제출할 수 있습니다.

부적절한 경우 서버에 직접 데이터를 게시하여 페이지를 완전히 우회 할 수도 있습니다.

클라이언트 측 유효성 검사 이외에 또는 클라이언트 측 유효성 검사 대신 서버 측 유효성 검사를 수행하는 경우 이러한 시나리오를 방어 할 추가 기회가 있습니다.

8

Fiddler, Noscript, Web Developer 등과 같은 다양한 도구를 사용하여 클라이언트 측 자바 스크립트 유효성 검사를 비활성화하고 서버로 전송되는 데이터를 수정할 수 있습니다. 데이터 유형 및 서버가 수행하는 작업에 따라 SQL 주입 공격을 시작하거나 서버 보안을 손상 시키거나 단순히 가짜 데이터를 저장할 수 있습니다.

간단한 예제 : 클라이언트 측 유효성 검사를 통해 우편 번호가 5 자리 또는 5 자리 + 4 자리인지 확인하십시오. 클라이언트 측 스크립트를 비활성화하면 24 자리 값을 그대로 둘 수 있습니다. 서버가 더 이상 값을 확인하지 않고 데이터베이스가 24 자리를 모두 저장할 수 있으면 위조 데이터를 저장했습니다.

+0

이 도구에 대해 문의 해 주셔서 감사합니다. – Xaisoft

0

사실 서버 쪽 유효성 검사와 함께 클라이언트 쪽 유효성 검사에 보안상의 큰 이점이 있습니다. 클라이언트에서주의 깊게 유효성을 검사하면 서버로 들어오는 모든 트래픽이 깨끗해야합니다. 공격자를 제외하고. 따라서 서버 측 공격 탐지 기능을 훨씬 향상시킬 수 있습니다. 큰 계획에서, 아마도 응용 프로그램을 보호하기 위해 할 수있는 가장 중요한 작업 일 것입니다. 자세한 내용은 OWASP ESAPI IntrusionDetector 또는 OWASP AppSensor를 참조하십시오.

아, 물론 공격이 클라이언트에서 시작되고 DOM 기반 XSS처럼 끝나면 클라이언트 측에서 유효성을 검사하고 인코딩해야합니다.

+1

필자는 귀하의 요지를 보았으나, 서버 측 유효성 검증 외에도 클라이언트 측 유효성 검증을 주장하고 있음을 분명히해야합니다. –

+0

감사합니다. –

관련 문제