기존의 Factory를 이용하지 않은 방법으로 new를 통해 UserDao에서 다음과 같이 생성했는데 이 방법은 UserDao가 사용할 구체적인 클래스를 알고 있어야한다는 점이문제가 있다. 왜냐면 UserDao는 ConnectionMaker 인터페이스 뿐만 아니라, DConnectionMaker를 사용하겠다는것 까지 관리하고 있는 셈이다.
public UserDao() {
connectionMaker = new DConnectionMaker();
}
따라서 최종적으로 만들어진 방법이 DaoFactory이다. DaoFactory는 런타임 시점에 UserDao가 사용할 ConnectionMaker타입의 오브젝트를 컨테이너 설정을 통해 결정하고 이를 생성하고 UserDao의 생성자 파라미터로 주입하여 UserDao가 DConnectionMaker와 관계를 가지도록 해준다 이러한 부분이 의존성 주입을 의미하고 UserDao는 ConnectionMaker 인터페이스와만 의존관계를 이루게 된다.
직접 생성하게된 Factory는 호출할때 마다 오브젝트가 달라지고 스프링 Factory는 호출해도 같은 오브젝트를 리턴한다. 이는 스프링 Factory는 싱글톤 패턴으로 구성되어 있기 때문이다.
2. 싱글톤 레지스트리로서의 애플리케이션 컨텍스트
스프링은 기본적으로 별다른 설정을 하지 않으면 내부에서 생성하는 빈 오브젝트를 싱글톤 오브젝트로 생성한다. 애플리케이션 컨텍스트는 이러한 싱글톤 객체를 저장하고 관리하는 레지스트리 역할을 한다. 이때 스프링에서의 싱글톤은 JAVA 싱글톤 디자인패턴과 비슷한개념이지만 구현방법은 다르다.
싱글톤을 사용하는 이유는 스프링이 처음 설계 되었을때 서버에서 수백 수천번씩 요청을 받아 처리 할 환경이 필요했는데 이를 요청이 올때마다 오브젝트를 생성한다고 가정하면 오브젝트 생성이 너무 많아지고, 가비지 컬렉션의 성능이 좋아짐에도 서버에 부하가 온다 따라서 싱글톤 패턴을 선택하였다.
기존 JAVA 싱글톤 패턴
1. 기본방법
사용자가 getInstance를 통해 Single 객체를 사용할 때 객체가 null이면 생성하고 null이 아니면 기존의 것을 가져다 사용하는 방식. 하지만 멀티 스레드 환경에서 두개의 스레드가 null일때 접근하면 하나만 생성되지 않을 수 있음.
public class Single {
private static Single single;
private Single() {};
public static Single getInstance() {
if(single == null) {
single = new Single();
}
return single;
}
}
2. synchronized를 이용한 방법
이 방법을 이용하면 멀티스레드 환경에 적절하게 대응 할 수 있으나 속도가 너무 느리다는 단점이 있다.
public class Single {
private static Single single;
private Single() {};
public static synchronized Single getInstance() {
if(single == null) {
single = new Single();
}
return single;
}
}
3. volatile 이용하기
다음과 같은 volatile을 이용해 미리 객체를 선언하고 이후에 getInstance를 이용한 방식이다. 만약 Single을 사용하지 않을 경우에도 객체가 생성되어 있다는 단점이 있다.
public class Single {
private static volatile Single single = new Single();
private Single() {};
public static synchronized Single getInstance() {
return single;
}
}
4. holder 이용하기
다음과 같은 내부 클래스를 이용한 방법으로 싱글톤을 구현할 수 있다. Single이 로드되지 않으면 먼저 생성되어있는 객체도없을 뿐더러, getInstance가 불릴때 Holder클래스가 로드되면서 single객체를 생성하므로 스레드에도 안전하다.
public class Single {
private Single() {};
private static class Holder {
private static final Single single = new Single();
}
public static Single getInstance() {
return Holder.single;
}
}
싱글톤의 사용은 전역 상태를 만들 수 있어 바람직하지 못하다. (public static이므로)
이러한 단점으로 인해 스프링에서는 직접 싱글톤 형태의 오브젝트를 만들고 관리하는 기능을 제공하는데 이를 싱글톤 레지스트리 라고 한다.
싱글톤 레지스트리는 JAVA 싱글톤과 달리 ApplicationContext가 로드될때 IOC/DI를 통해 빈을 생성하고 빈목록에 이를 저장해 놓고 이후에 ApplicationContext를 이용해 빈을 가져다가 사용하는 방식으로 되어있다. 즉 ApplicationContext가 싱글톤 레지스트리로서의 역할을 한다.
싱글톤 레지스트리의 장점
private static 이 아닌 평범한 자바 클래스를 싱글톤처럼 활용할 수 있게 한다. 이는 public 생성자를 가질 수 있고 앞서나온 단점이 해결된다.
3. 싱글톤과 오브젝트의 상태
이러한 싱글톤은 멀티스레드 환경이라면 여러 스레드가 동시에 접근할 수 있는 문제가 생기므로 상태정보를 가지고 있지 않은 stateless방식으로 만들어져야한다.
만약 다수의 스레드가 싱글톤 오브젝트의 변수를 수정하게 되면 서로 값을 덮어쓰고 자신이 저장한 값이 아닌 값을 읽어올 수 있기 때문에 기본적으로 인스턴스 필드의 값을 변경하고 유지하는 상태유지 방식으로 만들지 않는다.
따라서 DB나 서버의 리소스로부터 생성한 정보는 파라미터, 로컬 변수, 리턴 등으로 해결하면 된다.
다음과 같은 문제가 생기는 Dao가 있다 싱글톤으로 빈이 만들어지는데 Connection 변수와, User를 로컬변수가 아닌 private 변수로 선언했다.
이렇게 되면 User와 Connection는 매번 새로운 값으로 값이 바뀌는 상태정보를 가지고있으므로 문제가 생길 수 있으므로 잘못된 방법이다. 하지만 connectionMaker는 처음에만 값이 정해지고 이후는 읽어서 사용하는 읽기정보이므로 사용해도 무방하다.
싱글톤에서 문제가 생기는 UserDao
public class UserDao {
private ConnectionMaker connectionMaker;
private Connection c;// 문제가 되는 부분
private User user; //문제가 되는부분
public User get(String id) throws ClassNotFoundException, SQLException {
this.c = connectionMaker.makeConnection();
...
}
}
앞선 Dao를 분리하는 작업을 하면서 생성한 오브젝트를 스프링에서는 빈이라고 부른다. 스프링에서 이러한 Bean을 IoC방식에 따라 생성하고 관계를 설정하는것을 컨테이너(빈 팩토리)가 담당한다. 보통 빈팩토리 대신 application context를 주로 사용한다. application context는 빈 팩토리보다 좀 더 확장된 기능을 가지고 있고 일종의 설정 파일을 읽어 빈을 생성하고 관계를 정의해주는 역할을 담당한다.
1. 컨테이너 설정파일
다음과 같이 Java로 설정파일을 작성할 경우 @Configuration이라는 어노테이션에 따라 이 클래스를 컨테이너가 사용할 설정 파일임을 명시한다. 또한 @Bean 어노테이션에 따라 오브젝트 생성을 담당하는 IoC기반의 메소드임을 표시한다.
@Configuration
public class DaoFactory
@Bean
public UserDao userDao(){
return new UserDao(connectionMaker());
}
@Bean
public ConnectionMaker connectionMaker() {
return new DConnectionMaker();
}
}
2. 컨테이너 실행
public class UserDaoTest
public static void main(String[] args) throws ClassNotFoundException, SQLException {
ApplicationContext context = new AnnotationConfigApplicationContext(DaoFactory.class);
UserDao dao = context.getBean("userDao", UserDao.class);
....
}
3. 컨테이너(애플리케이션 컨텍스트) 동작 방식 및 장점
동작방식
@Configuration이 붙은 설정파일을 읽고 @Bean이 붙은 메소드를 가져와 빈 목록을 만들어둔다
public class User {
String id;
String name;
String password;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
}
이후 Mysql을 사용하여 id, Name, Password를 가진 테이블을 생성한다.
이후 다음과 같은 UserDao를 만든다. 사용자 생성, 조회 메소드를 가진 Dao 이다.
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
public class UserDao {
public void insertUser(User user) throws ClassNotFoundException, SQLException {
Class.forName("com.mysql.jdbc.Driver");
Connection c = DriverManager.getConnection("jdbc:mysql://localhost/test?serverTimezone=UTC", "root", "1234");
PreparedStatement ps = c.prepareStatement("INSERT INTO USERS(ID, NAME, PASSWORD) values(?,?,?)");
ps.setString(1,user.getId());
ps.setString(2,user.getName());
ps.setString(3,user.getPassword());
ps.executeUpdate();
ps.close();
c.close();
}
public User getUserList(String id) throws ClassNotFoundException, SQLException {
Class.forName("com.mysql.jdbc.Driver");
Connection c = DriverManager.getConnection("jdbc:mysql://localhost/test?serverTimezone=UTC", "root", "1234");
PreparedStatement ps = c.prepareStatement("SELECT * FROM USERS WHERE id = ?");
ps.setString(1,id);
ResultSet rs = ps.executeQuery();
rs.next();
User user = new User();
user.setId(rs.getString("id"));
user.setName(rs.getString("name"));
user.setPassword(rs.getString("password"));
rs.close();
ps.close();
c.close();
return user;
}
}
메인 코드를 다음과 같이 작성하면 정상적으로 동작하는것을 확인할 수 있다. 하지만. 이는 함수마다 connection을 반복적으로 진행하는 좋지 못한 방법이다. 만약 1000개의 함수가 존재하는데 비밀번호가 바뀐다면 1000번 수정해야한다. 따라서 DAO의 분리를 통해 다음과 같이 수정해보자.
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
public class UserDao {
public void insertUser(User user) throws ClassNotFoundException, SQLException {
Connection c = getConnection();
...
}
public User getUserList(String id) throws ClassNotFoundException, SQLException {
Connection c = get Connection();
...
}
private Connection getConnection() throws ClassNotFoundException, SQLException {
Class.forName("com.mysql.jdbc.Driver");
Connection c = DriverManager.getConnection("jdbc:mysql://localhost/test?serverTimezone=UTC", "root", "1234");
return c;
}
}
이렇게 된다면 getConnection함수를 호출하여 사용하므로 이전과 같은 문제를 해결할 수 있다.
이러한 Dao클래스를 외부에서 가져다 사용한다고 하자, A회사 B회사가 각기 다른 DB를 사용하고 Connection을 독자적으로 적용하고싶다고 하자 어떻게 제공할 수 있을까?
상속을 통한 확장
다음과 같이 상속을 통해 확장할 수 있다. A,B회사는 각각 UserDao를 상속받고 getConnection을 오버라이딩하여 Dao클래스를 만들 수 있다.
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
public abstract class UserDao {
public void insertUser(User user) throws ClassNotFoundException, SQLException {
Connection c = getConnection();
...
}
public User getUserList(String id) throws ClassNotFoundException, SQLException {
Connection c = get Connection();
...
}
public abstract Connection getConnection() throws ClassNotFoundException, SQLException {
//추상메소드로 구현하여 구현을 서브클래스에서 담당한다
}
}
이렇게 해결한 Dao에도 단점이 있다 상속을 받았다 보니 다른 상속을 받을 수 없다는 단점과, 슈퍼클래스와 하위클래스의 긴밀한 결합이다. 예를들어 슈퍼클래스를 수정하면 모든 서브 클래스를 수정하거나 다시 개발해야할 수 있다.
따라서 이를 별도의 클래스로 분리하여 사용하는 방법을 이용한다. 다음과 같이 Connection부분을 별도의 클래스로 분리한다.
이후 다음과 같이 수정한다. 이렇게 수정하게되면 connection, dao부분이 분리가 되긴 하였으나, UserDao가 SimpleConnectionMaker에 종속 되어 있다 보니, A,B회사에서 Connection부분을 확장하기에 적합하지 않다.
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
public class UserDao {
private SimpleConectionMaker simpleConnectionMaker;
public UserDao(){
simpleConnectionMaker = new SimpleConnectionMaker();
//생성자를 통해 다음과 같이 만들어놓고 함수에서 사용하도록 하게 한다.
}
public void insertUser(User user) throws ClassNotFoundException, SQLException {
Connection c = simpleConnectionMaker.makeNewConnection();
...
}
public User getUserList(String id) throws ClassNotFoundException, SQLException {
Connection c = simpleConnectionMaker.makeNewConnection();
...
}
}
따라서 인터페이스를 활용하면 다음과 같이 해결할 수 있다.
ConnectionMaker interface
public interface ConnectionMaker {
public Connection makeConnection() throws ClassNotFoundException, SQLException;
}
ConnectionMaker구현 클래스
public class AConnectionMaker implements ConnectionMaker {
...
public Connection makeConnection() throws ClassNotFoundException, SQLException {
// A회사의 Connection을 생성하는 코드
}
}
UserDao
public class UserDao {
private ConnectionMaker connectionMaker;
public UserDao(){
connectionMaker = new AConnectionMaker();
}
public void insert.....
public User get.....
}
다음과 같이 구현하게 된다면 B사도 Interface에 맞는 클래스만 구현주면 되므로 UserDao부분을 고칠 이유가 사라진다 하지만 AConnection 클래스의 생성자를 호출해서(connectionMaker = new AConnectionMaker();) 오브젝트를 생성하는 부분이남아 있으므로 완벽하게 분리되지 않았다.
따라서 우리는 new AConnectionMaker로 객체를 생성하는 방법이 아닌 파라미터로 객체를 넘겨 받아 이를 구현하도록 하겠다.
UserDao 생성자부분
public UserDao(ConnectionMaker connectionMaker) {
this.connectionMaker = connectionMaker;
}
main클래스
import java.sql.SQLException;
public class UserDaoTest {
public static void main(String[] args) throws ClassNotFoundException, SQLException {
// TODO Auto-generated method stub
ConnectionMaker connectionMaker = new DConnectionMaker(); //UserDao부분이 아닌 main에서 객체 생성
UserDao dao = new UserDao(connectionMaker); //객체 주입
}
}
이렇게 이용하게 된다면 main 클래스만 수정하고 UserDao는 완벽하게 분리되게 된다. 공부를 하면서 Dao를 분리시키는 작업이 의존성 주입이랑 비슷하다는것을 알게 되었다.
원격으로부터 소스코드 또는 실행파일을 무결성 검사 없이 다운로드 받고 이를 실행할경우 발생하는 변조, DNS spoofing 또는 전송시의 코드 변조 등의 방법을 이용하여 공격자가 악의적으로 파일이나 코드를 변경할 수있다.
2. 안전한 코딩 방법
암호화하여 코드나 파일을 제공하고 이를 클라이언트가 검증하도록 한다.
3. 예시
다음은 URLClassLoader를 사용하여, 원격의 파일을 다운로드하는 예제이다. 다운로드 대상 파일에 대한 무결성 검사를 수행하지 않을 경우, 파일변조로 인한 피해가 발생할 수 있다.
공개키 방식의 암호 알고리즘을 통하여 전송파일을 암호화하고, 사용자는 이를 복호화 하여 변조 유무를 판단한다.
공개키 방식이란?
공개키 암호화 방식에는 비밀키와 공개키가 존재하는데 비밀키는 서버 쪽에 가지고 있으며 공개되어서는 안 되고, 공개키는 누구에게나 공개되어도 괜찮은 키이다. 먼저 클라이언트는 공개키를 통해 텍스트를 암호화하고 이는 비밀키로만 복호화할 수 있다 따라서 다른 사람이 정보를 가로채더라도 비밀키만 안전하다면 괜찮은 방식이다. (예시는 공개키를 통해 복호화함)
다음의 예에서는 파일을 다운로드할 때, 파일의 무결성에 대한 검사를 하지 않고 있다. 따라서 인증된 사이트로 위장하거나, 중간에 파일의 내용을 악의적으로 바꿀 경우, 이에 대하여 대처를 할 방법이 없다.
파일의 내용이 공개되어서는 안 될 경우는 모든 파일을 암호화 하지만, 공개되어도 괜찮은 경우네는 체크섬을 이용하여 파일의 내용이 변경되었는지 확인하는것이 더 효과적이다. 다음은 체크섬의 예시이다.
체크섬이란?
네트워크를 통해 전달된 값이 변경되었는지를 검사하는 값으로 무결성을 제공합니다.
전달되는 값이 중간에 오류 또는 해킹을 통해서 변질되는경우를 대비해 체크섬값을 같이 보내어 무결성을 확인합니다.
1. 수신측에서 IP헤더를 16비트씩 나눈다.
2. 나눈 비트중 체크섬은 메시지를 보낸쪽에서 체크섬을 구해서 포함시켜 보낸 값이므로 이 값으로 내가 구한 체크섬값과 비교하여 사용한다 그림에서 b1e6을 제외한 나머지 값을 다 더한다.
클라이언트가 서버에 첫 request를 보내면, 해당 서버의 클라이언트에게 유니크한 ID를 부여하고 이를 세션 ID라고 부른다.
세션의 원리
클라이언트가 서버로 request를 보낼시 세션 ID를 만들고 이를 쿠키를 통해 전달함
클라이언트는 이후 request마다 쿠키에담긴 세션ID를 보내고 서버는 이가 유효한지 검증함
1. 정의
응용 프로그램이 외부 입력값에 대한 신뢰를 전제로 보호 메커니즘을 사용하는 경우 공격자가 입력값을 조작할 수 있다면 보호 메커니즘을 우회할 수 있게 된다. 개발자들이 흔히 쿠키, 환경변수 또는 히든필드와 같은 입력값이 조작될 수 없다고 생각하지만 공격자는 이를 변경할 수 있고 이는 에러로 이어진다.
2. 안전한 코딩기법
상태 정보나 민감한 데이터는 서버에 저장하고 보안확인 절차도 서버에서 진행한다.
3. 예시
다음과 같이 사용자의 역할을 설정할 때 브라우저의 쿠키의 할당된 값을 사용하면 쿠키 값이 변경되는 경우 사용자의 역할이 의도하지 않은 값으로 할당될 수 있다.
따라서 사용자 권한, 인증여부 등 중요한 정보는 사용자의 입력값이나 쿠키가 아닌 서버에 있는 세션값을 비교하여 활용한다.
정수형 변수의 오버플로우는 정수값이 증가하면서, 허용된 가장 큰 값보다 더 커져서 실제 저장되는 값은 아주 작은 수 이거나, 음수인 경우를 의미한다.
2. 안전한 코딩기법
언어 별 정수타입의 범위를 확인하여 사용한다. 정수형 변수를 연산에 사용하는 경우 결과값의 범위를 체크하는 모듈을 사용한다. 특히 외부 입력값을 동적으로 할당하여 사용하는 경우 변수의 값 범위를 검사하여 적절한 범위내에 존재하는지 확인한다.
3. 예시
다음의 예제는 외부의 입력을 이용하여 동적으로 계산한 값을 배열의 크기(size)를 결정하는데 사용하고 있다. 만일 외부 입력으로부터 계산된 값이 오버플로우에 의해 음수값이 되면 배열의 크기가 음수가 되어 문제가 발생할 수 있다.
따라서 size값이 음수인지 아닌지 검사하는 부분이 필요하다
4. 추가 예시
피드백받은 byte overflow 예시이다.
다음과 같이 InetAddress의 getByName 이용하면 127.0.0.1이 byte배열로 변하게 된다 즉 byte[] i = {127, 0, 0, 1}로 변환하게 된다. 이를 BigInteger에 담아서 BigInteger를 다시 Byte 배열로 변환하여 사용할 수 있다.
import java.math.BigInteger;
import java.net.InetAddress;
public class test {
public static void main(String[] args) {
// TODO Auto-generated method stub
BigInteger i = null;
try {
InetAddress inet = InetAddress.getByName("127.0.0.1");
System.out.println(inet.getAddress()[3]);
i = new BigInteger(inet.getAddress());
} catch (Exception e) {
e.printStackTrace();
}
System.out.println(i.toByteArray());
}
}
127.0.0.1을 BigInteger로 변환한 결과는 다음과 같다
하지만 만약 127.0.0.1 대신 128.0.0.1을 사용하게되면 결과는 다음과 같다.
이를 다시 바이트 배열로 변환하여 출력하게되면 다음과 같은 -128.0.0.1이 출력된다
이는 byte가 -128~127까지 표현가능한데 128을 입력했기 때문에 다음과 같은 오버플로우가 발생하는것이다. 이를 정확하게 사용하기 위해서는 저장된 -128을 0xFF(11111111)과 &연산하거나 결과값에 256을 더해주는 방법으로 unsinged처럼 표현할 수 있다.
