PHP, HTML, CSS, 자바 스크립트 양식 보안

Question

보안 관련 질문이 있습니다. 나는 (특히 라디오 버튼) 여러 가지 형태가있다, HTML, CSS, PHP, 자바 스크립트 (jQuery를)로 프로그램 웹 사이트 ... 웹 사이트 전반에 걸쳐

있습니다. 사용자가 선택하고 양식을 작성하면

는, 선택된 라디오 버튼의 값을 취하여 처리하기 위해 서버에 전송한다는. 서버는 또한 값을 가져 와서 데이터베이스에 연결합니다.

내 관심은 이것이다 :

하는 방법 (예 : 구글 크롬의 디버깅/개발자 도구 모듈 등) 개발자 도구/소스 편집기를 사용하여 수동으로 라디오 버튼의 값을 변경, 이전에 타격에서 사람을 방지 할 수 있습니다 제출 버튼? 양식을 제출하기 전에 사람들이 라디오 버튼 입력 값을 수동으로 변경할 수 있을지 걱정됩니다. 그들이 실제로 그것을 할 수 있다면, 그것은 내가 만들고있는 대본의 목적을 완전히 무너 뜨릴 것입니다.

나는 이것이 의미가 있기를 바랍니다.

감사합니다.

요한이

Answer 1

가 어떻게 개발자 도구/소스 (예 : 구글 크롬의 디버깅/개발자 도구 모듈 등) 편집기를 수동으로 라디오 버튼의 값을 변경을 사용하여, 이전에 타격에서 사람을 방지 할 수 제출 단추?

수 없습니다. 서버로 보내지는 것을 제어 할 권한이 없습니다. 데이터가 데이터베이스에 삽입하기 전에 설정 무엇이든 요구 사항을 충족

는

테스트합니다. 확인되지 않으면이를 거부하고 HTTP 응답의 문제점을 설명하십시오.

Answer 2

브라우저에서 서버로 보낸 데이터는 양식 데이터, URL 매개 변수 및 쿠키를 포함하여 사용자 컨트롤 외부에서 조작 할 수 있습니다. PHP 코드는 유효한 값 집합을 알아야하며 합리적인 것처럼 보이지 않으면 요청을 거부해야합니다.

데이터베이스에 사용자 입력을 보낼 때 당신은 악의적 인 사용자가 입력 한 문자열이 SQL 쿼리의 의미를 수정할 수 있도록 할 것입니다. SQL Injection을 참조하십시오. 그리고 사용자가 입력 한 데이터를 표시 할 때 (다음 응답에 직접 또는 나중에 데이터베이스에서 다시 읽음), 사용자가 입력 한 문자열이 사용자의 원치 않는 자바 스크립트로 실행되는 것을 방지하기 위해 올바르게 인코딩해야합니다. 브라우저. Cross-site scripting를 참조하고 prevention cheat sheet

Answer 3

나는 이것에 쿠엔틴 응답과 함께 갈 것입니다. 클라이언트 측 유효성 검사는 결코 혼자서는 안되며, 서버 측 유효성 검사가 필요합니다. 대부분의 사용자는 클라이언트 측 유효성 검사를 통해 서버로의 왕복 시간을 절약 할 수 있지만 둘 다 언급 할 때 "누군가"가 잘못된 데이터를 보내지 않을 것이라는 보장은 없습니다.

그러므로 진언은 다음과 같아야합니다 항상 서버 측 유효성 검사

Answer 4

다른 사람이 이미, 당신은 방화범, TamperData 플러그인은, 자기가 만든 서버 (전송되는 데이터를 조작하지 못하도록 할 수 없습니다 말했다 변조 프록시 ...).

따라서 서버 측에서는 이어야합니다.은 클라이언트 유효성 검사가 전혀없는 것처럼 입력을 처리해야합니다.

외부 소스에서 응용 프로그램을 입력하는 사용자 입력을 신뢰하지 마십시오. 그것을 항상 확인하고, 살균하고, 그것을 벗어나십시오.

는 OWASP도 취약점 Client-side validation에 대한 스텁 페이지를 시작

- 재미 - 클라이언트 측 유효성 검사는 많은 사람들을 혼동하고 그들이 지금 뭔가 대신 취약점 고려하는 것이 많은 보안 취약점의 원인이었던 것으로 보인다 좋은.

우리는 급진적 일 필요가 없습니다. 클라이언트 측 유효성 검사가 여전히 유용하지만 데이터가 잘못되었다는 사실을 알기 전에 사용자가 서버 왕복을 먼저하지 않아도되는 것을 방지하기위한 용도로만 간주됩니다. 그렇습니다. 클라이언트 측 유효성 검사는 사용자의 편의를위한 것일뿐 서버의 보안에 대한 자산은 말할 것도 없습니다.

OWASP는 웹 보안에 유용한 리소스입니다. 그들의 section on data validation을보십시오. 가치 인용

조언 :

포함하는 검증은

검증은 모든 계층에서 수행해야합니다. 그러나 유효성 검사는 코드를 실행하는 서버의 기능에 따라 수행되어야합니다. 예를 들어, 웹/프리젠 테이션 계층은 웹 관련 문제를 검증해야하며, 지속성 계층은 SQL/HQL 삽입과 같은 지속성 문제에 대해 유효성 검사를 수행하고, 디렉토리 조회는 LDAP 주입을 확인해야합니다.

예외없이이 규칙을 준수하십시오.

Answer 5

클라이언트 측 유효성 검사는 양식을 제출하고 기다리기 전에 사용자의 편의를 위해 사용해야합니다 (예 : 필수 필드를 채우지 못한다는 경고 등). 서버로 가서 유효성을 검사 한 다음 수정하기 위해 다시 보내야합니다. 얼마나 아팠는가. 자바 스크립트가 당신이 뭔가를 엉망으로 만든 것을 그 자리에서 바로 알려주는 것이 더 낫습니다.

서버 쪽 유효성 검사는 보안을위한 것입니다.

Answer 6

이 시나리오에서는 값을 키로 사용하고 서버 측에서 값을 확인하는 것이 좋습니다.

누군가가 양식을로드 할 때마다 숨겨진 필드에 nonce을 발행하는 것도 고려하십시오. 양식을 거치지 않고 다른 사람이 데이터를 제출하기가 다소 어려워집니다.

자바 스크립트가 많이있는 경우에는 obfuscator를 통해 실행하는 것이 좋습니다. 해커가 논리를 따르기가 더 어려워 질뿐만 아니라 스크립트를 작고 빠르게로드 할 수 있습니다.

언제나 그렇듯이 해킹을 막을 수있는 마법의 탄환은 없지만 캐주얼 한 해커를 막을 수있을 정도로 바를 올리면 도전을 즐기는 사람에 대해 걱정할 수 있습니다.