Tech Log 🛠️

SQL Injction이란

    - 악의적인 사용자가 보안 상의 취약점을 의도적으로 이용하여 악의적인 SQL문을 주입하고 실행되게

      하여, 데이터베이스를 조작하는 행위

SQL Injection의 종류

    Error based SQL Injection4

         - 논리적 에러를 이용한 SQL Injection

         - 가장 대중적인 공격 기법이다.

         ex)

         SELECT * FROM Users WHERE id = 'INPUT1' AND password = 'INPUT2'

         라는 SQL 구문이 있다고 가정해보자.

         만약 사용자가 여기에

         'OR 1=1 -- 

         라는 SQL 문을 주입하게 된다면 이 사용자는 Users 디비에 있는 모든 데이터를 조회하게 된다.

         또한 보통 관리자 계정을 제일 먼저 만들기 때문에 2차 피해를 발생시킬 수 있다.

         SELECT * FROM Users WHERE id = ''OR 1=1 -- ' AND password = 'INPUT2'

         해석 : 'OR1=1 을 주입해줌으로써 구문이 항상 참이 되도록 하고 -- 을 주입해줌으로써 뒷 구문들을

                   모두 주석처리시킨다.

         결과 : 악의적인 사용자가 DB 데이터를 모두 조회할 수 있다.

    Union based SQL Injection

         - Union 명령어를 이용한 SQL Injection

         - 두 개의 쿼리문을 통합해서 하나의 테이블로 보여준다. 

         - Union 하는 두 테이블의 컬럼 수와 데이터 형이 같아야한다.

         ex)

         SELECT * FROM Board WHERE title LIKE '%INPUT%' OR contents '%INPUT%'

         이라는 구문에 악의적인 사용자가 

         'UNION SELECT null,id,passwd FROM Users-- 

         라는 구문을 주입했다면 사용자의 개인 정보가 게시글과 함께 화면에 보여지게 된다.

         SELECT * FROM Board WHERE title LIKE '% 'UNION SELECT null,id,passwd FROMUsers --

        %'AND contents '% UNION SELECT null,id,passwd FROM Users -- %'

         해석 : 싱글쿼터를 닫아주기 위한 ' 삽입 , Union 명령어를 통해 두 쿼리문을 합쳐줌으로써 하나의 테이

                   블로 보여지게 된다. 

         결과 : 사용자의 개인 정보가 게시글과 함께 화면에 보여지게 된다.

    Blind SQL Injection

•   Boolean based SQL

          -  특정한 값이나 데이터를 전달받지 않고, 단순히 참과 거짓의 정보만 알 수 있다.

          ex)

          SELECT * FROM Users WHERE id = 'INPUT1' AND password = 'INPUT2'

          라는 구문에 악의적인 사용자가,

          abc123' and ASCII(SUBSTR(SELECT name FROM INFORMATION_SCHEMA.tables WHERE 

          table_type = 'base table' limit 0,1),1,1) > 100 --

          라는 구문을 주입했다고 가정해보자.

          이것은 조회되는 테이블 명의 첫 글자만 따서 100이라는 값과 비교해주는 구문이다.

          만약 테이블의 첫번째 값이 100이상이라면 로그인 성공이 될것이고 , 아니라면 실패할 것이다.

          이 과정을 자동화 스크립트를 통해 빠르게 진행할 수 있다.

          SELECT * FROM Users WHERE id = 'abc123' and ASCII(SUBSTR(SELECT name FROM 

          INFORMATION_SCHEMA.tables WHERE table_type = 'base table' limit 0,1),1,1) > 100 --' AND                password = 'INPUT2'

          해석 : 조회되는 테이블의 첫번째 값만 아스키 코드와 비교해서 참, 거짓을 판별한다.

          결과 : 자동화 스크립크를 통해 빠르게 테이블 명을 알아낼 수 있다.

• Time based SQL

           - 서버로부터 참 거짓을 응답받아 데이터베이스를 유추

           ex)

           SELECT * FROM Users WHERE id = 'INPUT1' AND password = 'INPUT2'

           라는 구문에 악의적인 사용자가,

           abc123' OR (LENGTH(DATABASE())=1 AND SLEEP(2)) --

           라는 구문을 주입했다고 가정해보자.

           이 경우 구문에서 설정한대로 데이터베이스의 길이가 1이면 SLEEP(2) 가 동작함으로써 실행을 지연             시키고, 거짓이면 동작하지 않는다.

           SELECT * FROM Users WHERE id = 'abc123' OR (LENGTH(DATABASE())=1 AND SLEEP(2)) --'             AND password = 'INPUT2'

           해석 : 데이터베이스의 길이가 맞으면 SLEEP() 함수를 통해 실행을 지연시킨다.

           결과 : 악의적인 사용자가 데이터베이스의 길이를 유추할 수 있다.

http 프로토콜이란?

    - 웹에서 이루어지는 모든 데이터 교환의 기초이며 , 클라이언트 – 서버 프로토콜

특징

http의 특징은 크게 두 가지가 있다.

    1. 비연결 지향(Connectionless)

    - 웹 서버에게 요청한 서비스를 제공받으면 클라이언트는 연결을 종료시킨다.

      * HTTP 1.1 부터는 Keep-Alive 속성을 통해 연결을 지속시킬 수 있다.

    2. 상태정보 저장 안 함(Stateless)

    - 상태 정보를 유지하지않는다. 즉 , 클라이언트의 정보를 기억하지 못한다.

    - 요청 간 의존관계가 없기 때문에 같은 유저인지 지속적으로 인증을 해줘야한다.

따라서 HTTP의 이러한 특징 때문에 쿠키와 세션을 사용한다.

쿠키

    쿠키란 ?

    -서버에 저장되지 않고 개별 클라이언트에 저장되는 방식-

    -서버와 통신(Request) 시에 상태정보를 HTTP 헤더에 담아서 전송 !

    -유효시간을 설정할 수 있으며 설정한 유효시간이 끝나자 않으면 브라우저를 닫아도  

     인증이 유지된다.

    구성요소

      - 이름과 값으로 이루어져있다.

           Ex)

    단점

      - 브라우저에서 조작이 가능하기 때문에 중요한 데이터를 담을 수 없다.

세션 

    세션이란 ?

     - 브라우저에서 관리하는 쿠키와 달리 서버에서 관리한다.

     - 서버에서는 클라이언트언트를 구분하기 위해 SessionID 를 사용한다.

     - Session cookie 기반으로 동작하므로 , 브라우저가 종료되면 인증이 끝난다.

.

    세션ID는 뭐야?

     - 서버에서 클라이언트를 구분하기 위해 사용하는 값이다.

     - 클라이언트마다 부여되는 유일한 값이다.

     - 서버에서는 세션ID를 통해 세션DB 와 비교함으로써 사용자를 식별한다.

    어떻게 전송해?

     - 서버 응답 시 서버에 Request 시 쿠키를 통해 전달된다

       Set−Cookie: SESSIONID=qwe3121

     - 이후 요청마다 쿠키를 HTTP 헤더에 넣어서 전송한다.

     세션ID를 사용함으로써 장점, 단점

     - 모든 세션DB를 저장함으로써 서버에 부담이 커질 수 있다.

       -> 때문에 Redis 라는 빠르고 저렴한 DB를 주로 이용

     - 서버에 누가 로그인 했는 지 저장하기 때문에 여러가지 기능이 구현 가능하다.

       -> 사용자 관리 , 로그인 관리

관계형 데이터 베이스

관계형 DB는 테이블로 이루어져 있으며 , 테이블은 키와 값의 관계를 나타낸다.

이처럼 관계형 DB는 종속성을 관계로 표현한다.

여기서 말하는 키(key)란 행의 식별자로 이용되는 열을 말한다 ex) ID

관계형 데이터 베이스의 활용

만약 여러 유튜버들의 영상을 데이터 베이스에

표현하고 싶다고 가정해보자

위의 표처럼 다른 영상임에도 같은 유튜버의 창작물인 경우가 있다.

어떻게 하면 효과적으로 DB를 설계할 수 있을까 ?

이런 식으로 유튜버의 코드만을 따로 테이블로 만들어서 DB를 관리하는 실습을 해볼 것이다.

먼저 video라는 DB를 새로 생성해주었다.

두 개의 테이블을 생성해준 후 데이터를 넣어준다.

이제는 join으로 테이블을 합칠 차례다.

기본적인 LEFT JOIN 명령어를 통해서 테이블을 합쳐주었다.

하지만 코드 열이 중복되어 있어서 하나만 나오도록 설정해줄 필요가 있다.

AS 명령어를 통해서 video 테이블의 코드만 출력되도록 하였다.

오히려 더 복잡해지는 거 같은데, 이렇게 관계형 DB를 사용하면 장점이 뭘까?

관계형 DB를 사용하면,

1. 데이터의 분류, 정렬, 탐색 속도가 빠르다

2. 오랫동안 사용된 만큼 신뢰성이 높고, 어떤 상황에서도 데이터의 무결성을 보장해준다.

하지만,

기존에 작성된 스키마를 수정하기가 어렵고 데이터베이스의 부하를 분석하는 것이 어렵다라는

단점이 있다.

데이터베이스란 ,

구조화된 정보 또는 데이터의 조직화된 모음으로써 일반적으로 컴퓨터 시스템 내에 전자적으로 저장

데이터 베이스의 구조

여러 데이터는 표들로 구성되어 있다.

이 데이터들을 연관 된 항목에 맞게 그룹화 시키는 데 이것을 데이터 베이스 혹은 스키마 라고 한다.

또 스키마들이 모인 것이 데이터베이스 서버가 된다.

SQL(strutured query language)

이렇게 만들어진 데이터베이스 서버에 데이터를 얻으려면 SQL 이란것을 사용해야한다.

Sql을 사용함으로써 데이터를 쿼리 , 조작 정의하고 액세스를 제어할 수 있다.

스프레드 시트 vs 데이터 베이스

엑셀의 스프레드 시트를 사용하면 되는데 데이터 베이스를 사용함으로써 얻는 이점은 뭘까 ?

- 데이터 저장 및 조작 방법

- 데이터에 액세스 할 수 있는 사람

- 저장할 수 있는 데이터 양

스프레트 시트는 다양한 사용자에 맞게 설계된 것이 아니기 때문에 사용자가 적거나 데이터의 양이 많지 않은 경우에 적합하다.

하지만 데이터 베이스는 여러 사용자들에게 다양한 권한을 줄 수 있기 때문에 여러 사용자가 동시에 데이터베이스에 접근하여 안전하게 데이터를 얻을 수 있다.

데이터베이스 서버에 접속하기

DB 데이터를 다루고 싶으면 먼저 DB서버에 접속을 해야한다.

Mysql이 설치되있는 경로로 가서

Mysql –uroot –p 명령어를 입력해준다.

그리고 mysql 설치 시 설정했던 비밀번호를 입력해주면 서버로 접속할 수 있다.

Mysql 실습

DB와 테이블

DB 명령어

CREATE DATABASE 명령어를 사용해서 데이터베이스를 만들 수 있다.

DROP DATABASE 명령어를 사용해서 데이터베이스를 삭제할 수 있다.

SHOW DATABASES 명령어를 사용해서 현재 만들어져 있는 데이터 베이스를 조회할 수 있다..

Ex)

topic 데이터베이스를 만들려고 했지만 , 이미 존재하였다.

따라서 DROP 명령어를 이용하여 해당 DB를 삭제하고 다시 만들어주었다.

이제 use topic 명령어를 통해서 해당 DB를 이용해주도록 하자

TABLE 명령어 및 생성 실습

데이터 베이스를 만들었으면 거기에 들어갈 테이블들을 만들어 주어야한다.

테이블을 만들어주는 것은 CREATE TABLE 을 이용하면 된다.

이제 이 테이블들을 이용하여 CRUD 실습을 진행해볼것이다.

CRUD 란?

DB의 가장 기본이 되는 것으로

Create

Read

Update

Delete 를 의미한다.

Create

테이블에 어떤 데이터를 넣고 싶을 때, INSERT 명령을 사용하여 데이터를 넣을 수 있다.

Ex) INSERT INTO topic1(ID,col1,col2,created) VALUES("1","ROW1","ROW2",NOW());

Read

테이블의 정보를 불러오고 싶을 때 , SELECT 명령으로 테이블의 데이터를 읽을 수 있다,

Ex) SELECT * FROM topic1;

   SELECT id,col1 FROM topic1;

*  만일 조건에 맞는 데이터를 검색하고 싶으면 where문을 이용하면 된다.

UPDATE

테이블의 데이터 정보를 수정하고 싶을 때 , UPDATE 명령어를 통해 데이터를 변경할 수 있다.

DELETE

테이블의 데이터를 삭제해야 할 때, DELETE 명령으로 테이블의 데이터를 삭제할 수 있다.

* WHERE 뒤에 조건문을 꼭 달아주어야한다 !

 참고) 생활코딩 Mysql

 https://www.youtube.com/watch?v=h_XDmyz--0w&list=PLuHgQVnccGMCgrP_9HL3dAcvdt8qOZxjW

@RequestParam 에서 @ModelAttribute를 사용하기 까지의 변화를 알아보자

1.@RequestParam 을 통해 파라미터 직접 받기

@PostMapping("/add")
public String addItemV1(@RequestParam String itemName,
                        @RequestParam int price,
                        @RequestParam Integer quantity,
                        Model model) {
    Item item = new Item();
    item.setItemName(itemName);
    item.setPrice(price);
    item.setQuantity(quantity);
    itemRepository.save(item);
    model.addAttribute("item", item);
    return "basic/item";
}

해당 변수 이름에 맞는 파라미터를 직접 받고 itemRepository에 저장한다.

해당 item 객체를 모델에 전달한다.

2.@ModelAttribute를 통한 주입

@PostMapping("/add")
public String addItemV2(@ModelAttribute("item") Item item, Model model) {
    itemRepository.save(item);
    //model.addAttribute("item", item); //자동 추가, 생략 가능
    return "basic/item";
}

@RequestParam 을 생략해도 @ModelAttribute가 알아서 생성자를 입력해준다.

게다가 이렇게 넘어온 item 값을 자동으로 모델에 넘겨주기 때문에 

model.addAttribute 코드를 생략해도 된다.

따라서 코드를 더 간결하게 짤 수 있다.

만약 @ModelAttribute("item2")라고 입력해준다면, 모델에 "item2"라는 이름으로 넘겨준다.

3.@ModelAttribute의 이름 생략

@PostMapping("/add")
public String addItemV3(@ModelAttribute Item item) {
    itemRepository.save(item);
    return "basic/item";
}

@ModelAttribute의 이름을 생략해도 상관없다.

이 경우 item 클래스의 Item을 앞 글자만 소문자로 변경 후 모델 이름으로 넘겨준다.

model.addAttribute("item",item);

4. @ModelAttribute까지 생략

@PostMapping("/add")
public String addItemV4(Item item) {
    itemRepository.save(item);
    return "basic/item";
}

@ModelAttribute 까지 생략할 수 있다. 

이 경우에도 위와 똑같이 동작한다.

하지만 직관성이 너무 떨어지기 때문에 사용을 권하지 않는다.

강의 소스코드를 참고해보려는데 이런 오류들이 나타났다.

"Cannot resolve symbol"

여러번의 구글링 끝에 찾아낸 해결 방법

해당 소스코드 파일 경로의 .idea 폴더를 삭제한다.

그 다음 인텔리제이로 다시 build.gradle을 열어준다.

빌드가 끝난 후, file -> Project Structure 로 이동해준다.

SDK 버전확인 후 , Project 탭에서 SDK 버전을 선택해준다.

그 다음 확인을 해주면...!

더 이상 오류가 뜨지 않는다 !!

"Redirect를 왜 필요할까?"

PRG를 알아보기 전에 먼저 Rediect의 필요성을 알 필요가 있다.

만약 상품을 수정, 개발하는 메서드를 개발한다고 생각해보자 

@PostMapping("/addForm")
public String addCafe(@ModelAttribute Cafe cafe){
    cafeRepository.save(cafe);
    return "basicCafe/cafe";
}

카페 정보를 추가하는 메서드를 만들었다.

하지만 추가를 완료한 뒤 새로 고침을 누르게 된다면 어떻게 될까?

똑같은 정보들이 계속해서 입력될 것이다.

이는 Redirect를 설정하지 않았기 때문인데, 이렇게되면 마지막으로 서버에 전송한 데이터가 추가 메서드를 계속 실행시킨다.

POST, Redirect Get

PRG는 새로고침 시 똑같은 메서드가 계속해서 실행되는 것을 막아준다.

말 그대로 경로를 우회해주는 것이다. 

메서드 실행 완료 후 다른 경로로 호출해줌으로써 서버는 더 이상 똑같은 메서드를 반복하지 않게 된다!

그럼 이제 위에서 문제를 일으켰던 추가 메서드를 수정해보자

@PostMapping("/addForm")
public String addCafe(@ModelAttribute Cafe cafe){
    cafeRepository.save(cafe);
    return "redirect:/basicCafe/cafes"+ cafe.getId();
}

 이렇게 메서드를 수정해주면 리다이렉트를 적용시킴으로써 문제를 해결할 수 있다.

하지만

"cafe.getId() 처럼 URL에 변수를 더해서 사용하는 것은 URL 인코딩이 안되기 때문에 위험하다."

쉽게 설명하자면 변수에 띄워쓰기나 한글이 포함될 경우 서버가 인식할 수 있게 url인코딩을 해주어야하는데 

이것이 안된다는 것이다.

결국 또 다른 문제가 생겼다.

그리고 이를 해결할 수 있는 두가지 해결책이 제시되었다.

첫번째, @PathVariable 사용

@PostMapping("/edit/{cafeId}")
public String edit(@PathVariable Long cafeId,@ModelAttribute Cafe cafe){
    cafeRepository.update(cafeId,cafe);
    return "redirect:/basic/items/{cafeId}";
}

@PathVariable 을 사용하게 된다면 컨트롤러에 매핑된 값도 Redirect 값에 사용할 수 있다. 

두번째, RedirectAttributes 사용

@PostMapping("/addForm")
public String addCafe(@ModelAttribute Cafe cafe, RedirectAttributes redirectAttributes){
    Cafe savedCafe = cafeRepository.save(cafe);
    redirectAttributes.addAttribute("cafeId",savedCafe.getId());
    redirectAttributes.addAttribute("status",true);
    return "redirect:/basicCafe/items/{cafeId}";
}

RedirectAttributes 를 사용하게 되면, URL 인코딩도 해주고, pathVarible , 쿼리 파라미터까지 처리해준다.

이 메서드는 

localhost:8080/basic/cafes/3?status=true

를 반환해준다.

굳이 PathVariable을 쓸 필요도 없고 url 인코딩 걱정도 할 필요가 없다. 

게다가 status 파라미터까지 추가해준다 !! (바인딩 되지 않았을 경우)

파라미터는 타임리프 문법에서 ${param.status}로 조회가 가능하다

타임리프 사용법

<html xmlns:th="http://www.thymeleaf.org">

th:href="@{/css/bootstrap.min.css}" 

타임리프 선언을 해주어야 비로소 타임리프 문법을 이해할 수 있다.

타임리프를 사용하게 되면,

th:xx 속성이 붙은 부분은 서버사이드에서 렌더링 되며 , 기존 html 속성이 대체된다.(th 속성이 없으면 html 그대로 사용)

하지만 html 을 파일로 직접 열었을땐 th 속성은 무시된다.

1.URL 링크 표현식

th:onclick="|location.href='@{/basicCafe/items/edit/{cafeId}(cafeId=${cafe.id})}'|"

타임리프는 url링크를 @{...}로 표현한다.

이 경우 서블릿 컨텍스트를 자동으로 포함한다.

2.리터럴 대체 문법

location.href='/basic/items/add'

th:onclick="'location.href=' + '\'' + @{/basic/items/add} + '\''"

th:onclick="|location.href='@{/basic/items/add}'|"

리터럴 대체 문법을 사용하면 복잡한 표현식을 간결하게 표현할 수 있다.

3.반복출력

사용예시

<tr th:each="item : ${items}">

<tr th:each="cafe:${cafes}">
    <td><a href="cafe.html" th:href="@{/basicCafe/items/{itemId}(itemId=${cafe.id})}" th:text="${cafe.id}">1</a></td>
    <td><a href="cafe.html" th:href="@{|/basicCafe/items/${cafe.id}|}" th:text="${cafe.cafeName}">테스트 상품1</a></td>
    <td th:text="${cafe.open}">10000</td>
    <td th:text="${cafe.close}">10</td>
    <td th:text="${cafe.mocaPrice}">10</td>

</tr>

컬렉션의 수많은 <tr>,</tr> 하위 태그들을 포함해서 생성된다.

4.변수 표현식

th:text="${cafe.id}">1</a></td>

내용의 값을 th:text 값으로 변경해준다.

5.링크 표현식

th:href="@{/basic/items/{itemId}(itemId=${item.id})}

th:href="@{|/basic/items/${item.id}|}"

리터럴 대체 문법을 사용하면 복잡한 링크 표현식을 간결하게 표현할 수 있다.

"순수 HTML을 그대로 유지하면서 뷰 템플릿도 사용할 수 있는 타임리프의 특징을 네츄럴 템플릿이라 한다."

실무에서는 printLn 이 아닌 로깅을 통하여 정보를 출력해야한다.

@RestController
public class LogTestController {
    private final Logger log = LoggerFactory.getLogger(getClass());

    @RequestMapping("/log-test")
    public String logTest(){
        String name = "spring";

        log.trace("trace log = {}", name);
        log.debug("debug log = {}", name);
        log.info("info log = {}", name);
        log.warn("warn log = {}", name);
        log.error("error log = {}", name);

        log.debug("debug log={}",name);

        return "ok";
        
    }

먼저 클래스 레벨에 붙은 @RestController 에노테이션은 리턴 값을 Http 바디에 바로 입력해준다.

(@Controller 는 반환값을 뷰 이름으로 인식한다.)

@Slf4j
@RestController
public class LogTestController {
    //private final Logger log = LoggerFactory.getLogger(getClass());

또한 @sLf4j 어노테이션을 사용하면 로그 선언을 해줄 필요가 없다.

로그를 보면 trace와 debug 로그가 찍히지 않은 것을 볼 수 있는 데, 이는 application.properties 의 기본 설정과 관련이 있다.

# 기본 설정
logging.level.root=info
#debug 이하의 값을 출력해준다.
logging.level.hello.springmvc=debug

이렇게 설정을 하고 다시 로그를 찍어보자

이런식으로 로그 출력 단계를 조절할 수 있다.

(TRACE > DEBUG > INFO > WARN > ERROR)

log.debug("debug log={}"+name);

참고로 이와 같은 출력 형식은 사용하지 않는 것이 좋다.

출력 여부와 관계없이 문자열 + 연산을 수행하기 때문에 메모리 낭비가 되기 때문이다.

더 많은 기능은?

SLF4J

Logback Home (qos.ch)

Core Features (spring.io)