데이터 입력 검증-어디? 얼마나? [닫은]


28

데이터 입력 유효성 검사는 항상 내부적 인 어려움이었습니다.

레거시 응용 프로그램 재 작성 프로젝트에 실제 보안 프레임 워크 및 코드를 추가 할 때까지 (지금까지는 카드 기반의 강력한 레거시 보안 코드 및 데이터 유효성 검사를 거의 유지합니다), 얼마나 많은 유효성을 검사해야하는지 궁금합니다. 등

전문 Java 개발자로서 5 년 동안 데이터 입력 검증 및 보안 조치에 대한 개인 규칙을 작성하고 개선했습니다. 내 방법을 개선하고 싶을 때 여러분의 의견을 듣고 싶습니다. 일반적인 규칙과 절차는 훌륭하고 Java 고유의 ​​규칙과 절차도 좋습니다.

요약하면 다음은 간단한 설명과 함께 내 지침 (3 계층 웹 응용 프로그램 스타일에 노출됨)입니다.

  • 1 계층 클라이언트 측 (브라우저) : 최소한의 유효성 검사, 변하지 않는 규칙 (필수 전자 메일 필드, 하나의 항목 등을 선택해야 함); "6 ~ 20 자 사이"와 같은 추가 유효성 검사를 덜 자주 사용하면 변경에 대한 유지 관리 작업이 증가하므로 비즈니스 코드가 안정되면 추가 될 수 있습니다.

  • 1 계층 서버 측 (웹 통신 처리, "컨트롤러") : 이것에 대한 규칙은 없지만 여기서는 데이터 조작 및 어셈블리 / 파싱 오류 만 처리해야한다고 생각합니다 (생일 필드는 유효한 날짜가 아닙니다). 여기에 추가 검증을 추가하면 쉽게 지루한 프로세스가됩니다.

  • 2 단계 (비즈니스 계층) : 확고한 검증. 입력 데이터 형식, 범위, 값, 메소드를 언제라도 호출 할 수없는 경우의 내부 상태 확인, 사용자 역할 / 권한 등; 가능한 적은 사용자 입력 데이터를 사용하고 필요한 경우 데이터베이스에서 다시 검색하십시오. 검색된 데이터베이스 데이터도 입력으로 간주하는 경우 일부 특정 데이터가 DB에서 신뢰할 수 없거나 손상된 것으로 알려진 경우에만 유효성을 검사합니다. 강력한 타이핑이 여기서 대부분의 작업을 수행합니다 (IMHO).

  • 3 계층 (데이터 계층 / DAL / DAO) : 비즈니스 계층 만 데이터에 액세스해야하므로 여기에서 많은 검증이 필요하다고 믿지 않았습니다. 그러나 "여기"를 의미 할 때 "데이터베이스에 액세스하는 코드"또는 "SQL 실행 방법"을 의미 할 때 데이터베이스 자체는 완전히 반대입니다.

  • 데이터베이스 (데이터 모델) : 좋은 기본 키, 외래 키, 제약 조건, 데이터 유형 / 길이 / 크기를 사용하여 가능한 한 DB에서 부정확하고 손상된 데이터를 피할 수 있도록 신중하고 강력하며 자체 시행해야합니다. / precision 등-나는 그들 자신의 개인적인 토론을 가지고 있기 때문에 이것에서 트리거를 남기고 있습니다.

초기 데이터 유효성 검사는 훌륭하고 성능 측면에서는 좋지만 반복적 인 데이터 유효성 검사는 지루한 프로세스이며 데이터 유효성 검사 자체가 상당히 성가신 일임을 인정합니다. 그래서 많은 코더들이 그것을 건너 뛰거나 반쯤하는 이유입니다. 또한 모든 중복 유효성 검사는 항상 동기화되지 않은 경우 가능한 버그입니다. 요즘 내가 시간, 대역폭 및 CPU를 희생하여 대부분의 유효성 검사를 사례별로 처리하는 것을 선호하는 주된 이유입니다.

그래서 이것에 대해 어떻게 생각하십니까? 반대 의견? 다른 절차가 있습니까? 그런 주제에 대한 언급? 모든 기부가 유효합니다.

참고 : Java 방식의 작업을 생각하고 있다면 우리의 응용 프로그램은 Spring MVC 및 MyBatis (ORM 솔루션을 배제 한 성능 및 나쁜 데이터베이스 모델)를 기반으로하는 Spring 기반입니다. 스프링 보안을 보안 제공 업체로 추가하고 JSR 303 (Hibernate Validator?)을 추가 할 계획입니다.

감사!


편집 : 3 층에 대한 추가 설명.


내 조언은 Hibernate Validator의 작동 방식을 연구하는 것입니다. JSR 303이 지속성 동안 유효성 검사가 시작되는 데 유용하다는 것을 알지 못했지만 기본 유효성 검사에 의존하는 비즈니스 규칙이 있었기 때문에 일부 규칙은 지속성보다 훨씬 많이 적용되어야했습니다. 내 의견으로는, 그것은 매우 닫힌 모델에서 작동합니다. 어쩌면 내가 잘못 사용했을 수도 있지만 경험이 다른 사람을 찾지 못했습니다.
Vineet Reynolds 2016 년

@Vineet Reynolds Spring MVC에서 양식 유효성 검사에 이미 사용했지만 실제로는 훌륭한 조합입니다. 거의 노력하지 않고 세분화 된 메시지로 서버 측 유효성 검사를 받고 적절한 오류가 사용자에게 표시됩니다. 나는 여전히 이점을 확신하지 않고 서버 측 객체에서 완전히 테스트해야합니다. 이 샘플 포스트를 살펴보십시오. 그것이 바로 내가 사용한 방법입니다 : codemunchies.com/2010/07/…
mdrg

2
너무 많은 검증을 넣 습니다 . 어디에서나 사용자 입력 @ #! ! @@!
Chani

답변:


17

검증은 일관되어야합니다. 따라서 사용자가 웹 양식에 유효한 것으로 판단되는 일부 데이터를 입력하면 클라이언트 측에서 구현하지 않은 일부 기준으로 인해 데이터베이스 계층에서 거부해서는 안됩니다.

사용자에게는 한 페이지의 데이터를 입력하는 것이 데이터베이스로의 중요한 왕복 여행 후에 만 ​​잘못되었다는 것을 알기 위해 분명히 올바르게 표시하는 것이 더 성가신 일이 아닙니다. 프로세스에서 일부 클라이언트 유효성 검사를 중단 한 경우 특히 그렇습니다.

노출 될 때 다양한 수준의 검증이 필요하며이를 호출하는 사람을 제어 할 수는 없습니다. 따라서 가능한 한 검증을 한 곳에서 정의하고 필요한 곳에서 호출 할 수 있도록 준비해야합니다. 이 방법은 언어와 프레임 워크에 따라 다릅니다. 예를 들어 Silverlight에서는 서버 측에서 정의 할 수 있으며 적절한 속성을 사용하여 클라이언트 측에 복사되어 사용됩니다.


2
+1 물론입니다. ASP.NET MVC에 대해서도 똑같은 말을하려고했지만 당신은 저를 이겼습니다. :) 실제로, 시스템이 유효한 상태를 유지하기 위해 필요한 경우에만 검증이 필요합니다. 클라이언트 측과 같은 나머지 유효성 검사는 사용자에게 낭비되는 사용 성과 시간을 향상시키는 것이므로 이것이 주요 초점이되어야합니다. 일관성이 핵심입니다.
Ryan Hayes 2016 년

2
"왕복"에 대해서는 페이지에 적절한 오류 메시지가 표시되고 모든 필드가 이전에 입력 한 내용으로 채워져있는 한 문제가 없습니다. 오류가 발생하는 데 너무 오래 걸리면 추가 클라이언트 측 유효성 검사의 후보입니다.
mdrg

그리고 앱 전체에서 유효성 검사를 쉽게 복제 할 수 있다면이를 버릴 이유가 없습니다. 서버 측에서는 쉽지만 클라이언트 측에서는 언급 한 것과 같은 유효성 검사 도구가 없으면 매우 실망 스럽습니다 (예 : 서버에서 작성한 것과 같은 많은 JS 유효성 검사 코드 작성) .
mdrg

10

관계형 시스템에서 나는 그것을 3 계층 접근법으로 본다. 각 레이어는 아래 레이어로 제한됩니다.

  • 프리젠 테이션 / UI
    • 간단한 입력 검증
    • 입력 형식이 잘못된 경우 진행하지 마십시오
    • 사용성 향상 및 대역폭 / 시간 단축을 위해 클라이언트 요청을 서버에 "게이트"하여 왕복 시간을 줄입니다.
  • 논리
    • 비즈니스 로직 및 권한
    • 사용자가 허용되지 않은 작업을 수행하지 못하게 함
    • "파생 된"속성을 처리하고 여기에서 상태 (데이터베이스에서 비정규 화 된 것)
  • 데이터
    • 필수 데이터 무결성 계층
    • 쓰레기절대로 저장하지 마십시오
    • DB 자체는 데이터 형식 (int, date 등)을 시행합니다.
    • 데이터베이스 제약 조건을 사용하여 적절한 관계 보장

이에 대한 이상적인 해답은 한 곳에서 세 계층의 구속 조건을 정의 할 수있는 시스템입니다. 여기에는 SQL에 대한 일부 코드 생성과 클라이언트 및 서버에 대한 데이터 기반 유효성 검사가 필요합니다.

여기에 은색 글 머리 기호가 있는지 모르겠지만 ... JVM에 있으므로 클라이언트와 서버간에 JavaScript 유효성 검사 코드를 적어도 공유하기 위해 Rhino를 살펴 보는 것이 좋습니다. 입력 유효성 검사를 두 번 쓰지 마십시오.


Rhino를 살펴 보겠습니다. Spring MVC 양식 유효성 검사와 어떻게 든 통합 할 수 있다면 훨씬 좋습니다.
mdrg 2016 년

8

• 3 계층 (데이터 계층 / DAL / DAO) : 비즈니스 계층 만 데이터에 액세스해야하므로 여기에서 많은 검증이 필요하다고 믿지 않았습니다. .

이것은 너무 잘못되었습니다. 유효성 검사를 수행하는 가장 중요한 장소는 데이터베이스 자체입니다. 데이터는 거의 항상 응용 프로그램 이상으로 영향을받으며 (그렇지 않을 것이라고 생각하더라도) 데이터베이스에 적절한 제어를 설정하지 않는 것은 무책임합니다. 다른 요인보다이를 수행하지 않기로 한 결정으로 인해 데이터 무결성이 손실됩니다. 데이터 무결성은 데이터베이스를 장기간 사용하는 데 중요합니다. 좋은 데이터가 포함 된 데이터베이스 수준에서 무결성 규칙을 시행하지 못한 데이터베이스는 본 적이 없습니다 (그리고 문자 그대로 수천 개의 데이터베이스에서 데이터를 보았습니다).

그는 나보다 더 잘 말한다 : http://softarch.97things.oreilly.com/wiki/index.php/Database_as_a_Fortress


이 기사의 마지막 부분에 동의합니다.이 부분을 명확하게 밝히지 않은 것 같습니다. 자세한 내용으로 질문을 업데이트했습니다. 감사!
mdrg

2

위의 모든 것은 개발자와 관리자가 완벽하다고 가정하고 항상 완벽하게 실행되는 완벽한 코드를 작성합니다. 향후 소프트웨어 릴리스에서는 사용자가 상상하고 문서화하지 않은 모든 가정과 데이터를 시스템에 입력 한 사용자 및 해커에 대해 알고 있습니다.

물론, 너무 많은 검증은 나쁜 일이지만, 프로그램, 네트워크 및 OS가 완벽하다고 가정하면 해커는 방화벽을 통과하지 못하고 DBA는 수동으로 데이터베이스를 "조정"하지 않을 것입니다.

사물 주변에 경계 원을 그리며 보호하는 고장 모드를 식별하고 해당 경계에 대한 적절한 수준의 검사를 구현합니다. 예를 들어, 데이터베이스에 유효하지 않은 데이터가 표시되지 않아야하지만 데이터가 어떻게 발생하고 어떻게 발생합니까? 사용자는 누구입니까, 실패 비용은 얼마입니까?

실제 세계 보안 모델을 연구하십시오. 보안은 양파와 같은 계층이어야합니다. 두꺼운 벽 하나는 보안 성이 좋지 않은 것으로 간주됩니다. 데이터 유효성 검사는 동일한 방식으로 고려해야합니다.


1

유효성 검사에 대한 두 가지 짧은 일반적인 규칙 :

보장하지 않는 것을 호출하려는 경우 호출자에게 다시 전달할 수있는 방식으로 유효하지 않은 입력에 대해 알려주는 무언가 (오류, 예외)를 반환하여 유효성을 검사합니다.

데이터로 다른 작업을 수행하려는 경우 (결정, 수학, 저장 등) 유효성을 검사하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.