2024.06.15 검색어 공백 제한하기 2(고민)
현재 문제점
1. 공백 검색 및 sql 인젝션에 취약함
현재 프로젝트 상황
1. @NotBlank로 검색어를 값으로 가지는 SearchDTO의 변수 keyword의 유효성을 검사하려 함
2. notes table의 전체 데이터 확인 가능한 getList() 있음(getSearchList()로 인해 지금은 사용 안함)
3. SearchDTO(검색 조건, 검색어)를 매개변수로 받는 getSearchList() 있음 1. mybatis로 구현 ``를 사용해서 SearchDTO의 types에 값이 없으면 전체 조회를 함
BindingResult의 결과에 따라 에러가 있으면(keyword가 없으면) getList()를 실행하고, 없으면 getSearchList()를 실행하면 간단하게 해결될것 같았는데 그러면 getSearchList() 메소드 한개로 검색어가 있을때, 없을때를 모두 처리하기 위해 사용한 <where>
를 사용한 의미가 없어진다
생각해보기
우선 현재 프로젝트 상황을 떠나 처음으로 돌아가 생각해본 상황이 두가지 있는데 방향을 정하기 위해 작성해봤다.
- 입력을 받는 순간 검사를 한다.
- 예상되는 장점
- 당장에 구현하기는 편할것 같다.
- 서버로 요청을 줄일 수 있을것 같다.
- 서버로 요청을 하지 않아 응답이 빠르다.
- 예상되는 단점
- 보안에 취약할것 같다.(우회가 쉬울것 같음)
- 일관성 부족(브라우저 버전이나, 종류에 따라 달라질 가능성이 있을것 같다.)
- 서버측에서 검사를 하는 과정에 비해 사용자가 접근하여 임의로 수정하는 것이 쉬울것 같다.
- 다른 view에서 비슷한 과정이 필요할 경우 각 view에서 같은 코드를 작성해야 한다.(재사용성 떨어짐)
- 예상되는 장점
- 서버측에서 검사를 한다.
- 예상되는 장점
- 보안에 유리할것 같다(view에서 검사하는 것에 비하여)
- 코드의 재사용성이 좋을것 같다.
- 브라우저의 종류나 버전에 상관없이 일관성을 띌수 있다.
- 예상되는 단점
- 서버 요청이 증가하여 부하가 생긴다.
- 부하가 생길경우 응답이 느려질수 있다.
- 예상되는 장점
우선 내 생각대로라면
- 클라이언트 측에서 유효성을 검사하는 것은 보안과 무관하거나 신경쓰지 않아도 괜찮고, 서버에 의존적이지 않아도 될때 사용하는것이 좋을것 같다.
- 서버측에서 유효성을 검사하는건 보안과 관련이 있으며, 모든 사용자에게 일관된 값....? 경험?(표현을 모르겠다)을 주는것이 중요할때 하는것이 좋을것 같다.
그러므로 내 경우에는 사용자들끼리 자신의 메모를 선택해 공유하고 조회 가능하게 개발 할 계획이므로, 보안이 중요하고 비슷한 기능의 개발이 있을 것으로 예상되므로 서버측에서 유효성을 검사하는게 좋을것 같다는 판단이 섰다.
다만 지금의 내 수준과 포트폴리오에서 실제로 서버요청의 증가에 따른 부하는 처리 경험이 없고, 지식이 없기 떄문에 이 부분은 더 공부해봐야 할것 같다.
마지막으로 실제로 찾아봤다.
게시판 검색의 경우는 내가 들어가본 모든 사이트에서 서버측에서 처리를 하고 부적절한 문자열을 걸러냈다.
반대로 입력하는 순간 검사를 하는 경우는 회원가입을 할때 닉네임이나 비밀번호를 입력하는 순간 제한하는 경우에 쓰는것 같다.