Java 웹 공통 인터뷰 질문

jsp와 서블릿의 차이점은 무엇인가요? (추천 학습: v Java 공통 시험 문제 )

JSP는 Servlet이 됩니다. (JSP의 본질은 서비스이며, JVM은 Java 클래스만 식별할 수 있고 JSP의 코드는 인식할 수 없습니다. 코드는 Java 클래스로 컴파일됩니다. JVM에서 인식할 수 있는 것)

jsp는 페이지 표시에 더 좋고 서블릿은 논리 제어에 더 좋습니다.

서블릿에는 내장 객체가 없습니다. Jsp의 내장 객체는 HttpServletRequest 객체, HttpServletResponse 객체 및 HttpServlet 객체를 통해 얻어야 합니다.

Jsp는 Servlet을 단순화한 것입니다. Jsp를 사용하면 프로그래머가 클라이언트에 출력해야 하는 내용만 완성하면 됩니다. Jsp에 Java 스크립트를 클래스에 삽입하는 방법은 Jsp 컨테이너에 의해 완료됩니다. 서블릿은 완전한 Java 클래스이며 이 클래스의 Service 메소드는 클라이언트에 대한 응답을 생성하는 데 사용됩니다.

jsp에 내장된 객체는 무엇인가요? 기능은 무엇입니까?

JSP에는 9개의 내장 객체가 있습니다.

request: GET 또는 POST 요청의 매개변수를 포함하는 클라이언트의 요청을 캡슐화합니다.

response: 클라이언트에 대한 서버의 응답을 캡슐화합니다. 다른 객체를 얻을 수 있습니다.

session: 사용자 세션을 캡슐화하는 객체

application: 서버 실행 환경을 캡슐화하는 객체

out: 서버 응답을 출력하는 출력 스트림 객체 웹 애플리케이션의 객체

page: JSP 페이지 자체(Java 프로그램의 경우와 동일)

Exception: 페이지에서 발생하는 예외를 캡슐화하는 객체입니다.

JSP의 4가지 범위에 대해 알려주세요.

JSP의 네 가지 범위에는 페이지, 요청, 세션 및 애플리케이션이 포함됩니다. 구체적으로:

페이지는 페이지와 관련된 개체 및 속성을 나타냅니다.

request는 웹 클라이언트에서 발행한 요청과 관련된 개체 및 속성을 나타냅니다. 요청은 여러 페이지에 걸쳐 있을 수 있으며 페이지에 표시되어야 하는 임시 데이터가 이 범위에 포함될 수 있습니다.

session은 사용자와 서버가 설정한 세션과 관련된 개체 및 속성을 나타냅니다. 사용자와 관련된 데이터는 사용자 자신의 세션에 배치되어야 합니다.

application은 전체 웹 애플리케이션과 관련된 개체 및 속성을 나타냅니다. 이는 본질적으로 여러 페이지, 요청 및 세션을 포함하여 전체 웹 애플리케이션에 걸쳐 있는 전역 범위입니다.

세션과 쿠키의 차이점은 무엇인가요?

HTTP 프로토콜은 상태 비저장 프로토콜이므로 서버가 사용자의 상태를 기록해야 할 때 특정 사용자를 식별하는 메커니즘을 사용해야 합니다. 이 메커니즘은 장바구니와 같은 경우입니다. 단일 버튼을 사용할 경우 HTTP 프로토콜은 Stateless이므로 어떤 사용자가 이를 운영하고 있는지 알 수 없으므로 서버는 특정 사용자에 대한 특정 Session을 생성하여 사용자를 식별하고 사용자를 추적해야 쇼핑이 가능합니다. 카트 안에는 여러 권의 책이 있는 것으로 알려져 있습니다.

이 세션은 서버 측에 저장되며 고유 식별자를 갖습니다. 메모리, 데이터베이스, 파일 등을 포함하여 서버 측에 세션을 저장하는 방법에는 여러 가지가 있습니다.

클러스터링 시에는 세션 전송도 고려해야 합니다. 일반적으로 사용자 세션을 저장하기 위한 전용 세션 서버 클러스터가 있습니다. 이 때 세션 정보는 메모리에 저장되며 클래스(Memcached)와 같은 일부 캐싱 서비스가 사용됩니다. 세션을 넣습니다.

서버가 특정 고객을 어떻게 식별하는지 생각해 보세요.

이때 쿠키가 등장합니다. HTTP 요청이 이루어질 때마다 클라이언트는 해당 쿠키 정보를 서버에 보냅니다. 실제로 대부분의 애플리케이션은 세션 추적을 구현하기 위해 쿠키를 사용합니다. 세션이 처음 생성되면 서버는 세션 ID가 쿠키에 기록되어야 함을 HTTP 프로토콜로 클라이언트에 알려줍니다. 후속 요청을 통해 세션 ID가 서버로 전송되며 귀하가 누구인지 알 수 있습니다.

누군가가 클라이언트의 브라우저에서 쿠키가 비활성화되어 있으면 어떻게 해야 하는지 물었습니다.

일반적으로 이 경우 세션 추적을 위해 URL 재작성이라는 기술이 사용됩니다. 즉, 각 HTTP 상호작용에 대해 sid=xxxxx와 같은 매개변수가 URL에 추가되고 서버는 이를 따릅니다. 사용자를 식별합니다.

쿠키는 실제로 사용자 친화적인 시나리오에서 사용될 수 있습니다. 웹사이트에 한 번 로그인한 후 다음에 로그인할 때 다시 계정에 로그인하고 싶지 않다면 어떻게 해야 할까요?

이 정보는 쿠키에 기록될 수 있으며, 웹사이트 방문 시 웹사이트 페이지의 스크립트가 이 정보를 읽고 자동으로 사용자 이름을 채워 사용자를 용이하게 할 수 있습니다. 이는 사용자에게 약간의 달콤함을 주는 쿠키 이름의 유래이기도 합니다.

요약하자면:

세션은 사용자의 상태를 추적하기 위해 서버에 저장되는 데이터 구조입니다. 이 데이터는 클러스터, 데이터베이스 및 파일에 저장될 수 있습니다.

쿠키는 클라이언트가 사용자 정보를 저장하는 메커니즘으로 일부 사용자 정보를 기록하는 데 사용되며 세션을 구현하는 방법이기도 합니다.

세션이 어떻게 진행되는지 알려주세요.

사실 세션은 서버에 존재하는 해시 테이블과 유사한 파일입니다. 우리에게 필요한 정보가 여기에 저장되어 있으며, 필요할 때 꺼내서 사용할 수 있습니다.

내부의 키는 사용자의 세션 ID를 저장하며, 사용자는 서버에 요청을 보낼 때 이 세션 ID를 가져옵니다. 이때 해당 값을 추출할 수 있습니다.

클라이언트에서 쿠키를 비활성화해도 세션을 계속 사용할 수 있나요?

쿠키와 세션은 일반적으로 두 가지 독립적인 것으로 간주됩니다. 세션은 서버 측에서 상태를 유지하는 솔루션을 사용하는 반면 쿠키는 클라이언트 측에서 상태를 유지하는 솔루션을 사용합니다.

근데 쿠키를 비활성화하면 왜 세션을 얻을 수 없나요?

세션은 세션 ID를 사용하여 현재 대화에 해당하는 서버 세션을 결정하기 때문에 세션 ID는 쿠키를 통해 전달됩니다. 쿠키를 비활성화하는 것은 세션 ID를 잃는 것과 같으며 세션을 얻을 수 없습니다.

쿠키가 꺼져 있을 때 사용자가 세션을 사용한다고 가정합니다. 이를 달성하는 방법에는 여러 가지가 있습니다:

php.ini 구성 파일에서 "session.use_trans_sid = 1"을 설정하거나 "--enable"을 설정합니다. -trans-sid" 옵션을 컴파일할 때 PHP가 페이지 전체에 걸쳐 세션 ID를 자동으로 전달하도록 합니다.

URL을 통해 수동으로 값을 전달하고 숨겨진 양식을 통해 세션 ID를 전달합니다.

세션 ID를 파일, 데이터베이스 등에 저장하고 페이지 간 프로세스 중에 수동으로 호출하세요.

spring mvc와 struts의 차이점은 무엇인가요?

차단 메커니즘의 차이점

Struts2는 클래스 수준 차단입니다. Spring과 통합할 때 Struts2의 ActionBean 주입 범위는 프로토타입 모드 프로토타입이고 요청이 생성됩니다. setter 및 getter를 통해 데이터가 속성에 주입됩니다.

Struts2에서 Action은 매개변수를 수신할 때 속성을 통해 수신할 수 있습니다. 이는 속성 매개변수가 여러 메소드에 의해 공유됨을 나타냅니다.

Struts2의 Action 메소드는 URL에 대응할 수 있지만 해당 클래스 속성은 모든 메소드에서 공유됩니다. 이로 인해 해당 메소드를 식별하기 위해 주석이나 다른 메소드를 사용할 수 없으며 여러 인스턴스로만 설계될 수 있습니다.

SpringMVC는 메서드 수준 차단입니다. 한 메서드는 요청 컨텍스트에 해당하므로 메서드는 기본적으로 독립적이며 요청 및 응답 데이터에 독점적으로 액세스할 수 있습니다. 각 메소드는 동시에 URL에 해당합니다. 매개변수 전달은 메소드에 고유하며 메소드에 직접 삽입됩니다. 처리 결과는 ModeMap을 통해 프레임워크로 반환됩니다.

Spring 통합 중에 SpringMVC의 Controller Bean은 기본적으로 싱글톤 모드로 설정되므로 기본적으로 모든 요청에 ​​대해 하나의 컨트롤러만 생성되므로 기본 역할 도메인을 변경하려는 경우 공유 속성이 없어야 합니다. @Scope 주석을 추가하여 수정해야 합니다.

Struts2에는 자체 인터셉터 메커니즘이 있습니다. SpringMVC는 독립적인 Aop 방법을 사용하므로 Struts2의 구성 파일 양이 SpringMVC보다 커집니다.

기본 프레임워크의 차이점

Struts2는 Filter(StrutsPrepareAndExecuteFilter)로 구현되고, SpringMVC(DispatcherServlet)는 Servlet으로 구현됩니다. 컨테이너가 시작된 후 필터가 초기화됩니다. 서블릿보다 나중에 서비스가 중지된 후 충돌이 발생합니다. 서블릿은 Filter가 호출되기 전에 호출될 때 초기화되고, 서비스가 중지된 후에는 소멸됩니다.

성능 측면에서

Struts2는 클래스 수준 차단입니다. 각 요청은 SpringMVC의 메서드 기반 차단으로 인해 모든 속성 값 주입을 로드해야 하는 인스턴스의 새로운 작업에 해당합니다. , 단일 로드가 있습니다. 예제 패턴 Bean 주입입니다. 따라서 SpringMVC 개발 효율성과 성능은 Struts2보다 높습니다.

구성 측면에서

spring MVC와 Spring은 원활하게 작동합니다. 이 프로젝트의 관리 및 보안도 Struts2보다 높습니다.

SQL 주입을 피하는 방법은 무엇입니까?

PreparedStatement(간단하고 효과적인 방법)

정규식을 사용하여 들어오는 매개변수 필터링

문자열 필터

JSP에서 이 함수를 호출하여 잘못된 문자가 포함되어 있는지 확인하세요.

JSP 페이지 판단 코드

이것이 무엇인가요? XSS 공격을 피하는 방법은 무엇입니까?

CSS라고도 알려진 XSS 공격, 전체 이름 Cross Site Script(교차 사이트 스크립팅 공격)는 공격자가 XSS 취약점이 있는 웹 사이트에 악성 HTML 코드를 입력하는 것입니다. 사용자가 웹 사이트를 탐색할 때 이 HTML이 나타납니다. 공격 목적을 달성하기 위해 코드가 자동으로 실행됩니다.

XSS 공격은 SQL 주입 공격과 유사합니다. SQL 문은 데이터를 쿼리/수정/삭제하기 위한 사용자 입력으로 사용됩니다. XSS 공격에서는 사용자의 브라우저를 제어하고 이에 대한 일부 정보를 얻습니다. 사용자. XSS는 웹 프로그램의 일반적인 취약점입니다. XSS는 클라이언트 측에서 사용되는 수동적 공격 방법입니다.

XSS 방지의 일반적인 개념은 입력(및 URL 매개변수)을 필터링하고 출력을 인코딩하는 것입니다.

CSRF 공격이란 무엇이며 이를 방지하는 방법은 무엇입니까?

CSRF(교차 사이트 요청 위조)는 원클릭 공격 또는 세션 라이딩이라고도 합니다. 중국어 전체 이름은 교차 사이트 요청 위조입니다. 일반적으로 공격자는 사용자의 브라우저 요청을 위조하여 사용자가 방문을 인증한 웹사이트로 전송함으로써, 대상 웹사이트가 이를 수신하고 이를 사용자의 실제 작업으로 착각하고 명령을 실행하도록 합니다.

은 종종 계정 도용, 송금, 허위 메시지 전송 등에 사용됩니다. 공격자는 이러한 공격을 수행하기 위해 웹사이트의 요청 확인 취약점을 악용합니다. 웹사이트에서는 해당 요청이 사용자의 브라우저에서 비롯된 것인지는 확인할 수 있지만, 해당 요청이 사용자의 진정한 의도에서 비롯된 것인지는 확인할 수 없습니다.

피하는 방법:

1. HTTP 참조자 필드 확인

HTTP 헤더의 Referer 필드는 HTTP 요청의 소스 주소를 기록합니다. 정상적인 상황에서 보안 제한 페이지에 대한 액세스 요청은 동일한 웹사이트에서 이루어지며, 해커가 CSRF

공격을 구현하려는 경우 일반적으로 자신의 웹사이트에서만 요청을 구성할 수 있습니다. . 따라서 Referer 값을 검증함으로써 CSRF 공격을 방어할 수 있다.

2. 인증 코드를 사용하세요.

요청을 받은 후 백그라운드에서 인증 코드를 추가하세요. CSRF 방지를 위한 인증코드입니다. 하지만 이 방법은 사용자 친화적이지 않습니다.

3. 요청 주소에 토큰을 추가하고 확인합니다.

CSRF 공격은 해커가 사용자 요청, 모든 사용자 확인 정보를 완전히 위조할 수 있기 때문에 성공합니다. 이 요청에는 쿠키에 존재하므로 해커가 확인 정보를 알지 못한 채 사용자가 보유한 쿠키를 직접 사용하여 보안 확인을 통과할 수 있습니다. CSRF에 저항하는 핵심은 해커가 위조할 수 없고 해당 정보가 쿠키에 존재하지 않는 정보를 요청에 넣는 것입니다.

HTTP 요청에 무작위로 생성된 토큰을 매개변수로 추가하고, 요청에 토큰이 없거나 토큰 내용이 잘못된 경우 서버 측에 인터셉터를 설정하여 토큰을 확인할 수 있습니다. , CSRF 공격으로 인해 요청이 거부될 수 있는 것으로 간주됩니다.

이 방법은 사용자가 로그인하여 세션에 배치된 후 추천자를 확인하는 것보다 더 안전합니다. 그런 다음 요청 시마다 토큰을 세션에서 꺼내어 일치시킬 수 있습니다. 요청에 토큰을 비교하는데, 이 방법의 어려움은 토큰을 매개변수 형태로 요청에 추가하는 방법입니다.

GET 요청의 경우 요청 주소에 토큰이 추가되므로 URL은 http://url?csrftoken=tokenvalue가 됩니다.

POST 요청의 경우 토큰이 매개변수로 전달되도록 양식 끝에 를 추가하세요. 요청에 참여하는 양식입니다.

4. HTTP 헤더의 속성을 사용자 정의하고 확인합니다.

이 방법도 토큰을 사용하고 확인을 수행합니다. 이 방법은 이전과 동일합니다. 방법 차이점은 토큰이 매개변수 형식으로 HTTP 요청에 배치되지 않고 HTTP 헤더의 사용자 정의 속성에 배치된다는 것입니다.

XMLHttpRequest 클래스를 통해 이 유형의 모든 요청에 ​​csrftoken HTTP 헤더 속성을 한 번에 추가하고 토큰 값을 넣을 수 있습니다.

이것은 이전 방법에서 요청에 토큰을 추가해야 하는 불편함을 해결함과 동시에 XMLHttpRequest를 통해 요청한 주소는 브라우저의 주소 표시줄에 기록되지 않으므로 걱정할 필요가 없습니다. Referer를 통해 토큰이 유출되는 것에 대해 다른 웹 사이트로 이동하십시오.

위 내용은 Java 웹 공통 인터뷰 질문의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!