웹 사이트의 관리 섹션을 보호하기위한 모범 사례는 무엇입니까?

웹 사이트의 관리 섹션을 보호하기위한 모범 사례는 무엇입니까? [닫은]

---

특히 인증 / 액세스 관점에서 웹 사이트의 관리 섹션을 보호하기 위해 사람들이 모범 사례를 고려하는 것이 무엇인지 알고 싶습니다.

물론 SSL을 사용하고 모든 액세스를 로깅하는 것과 같은 명백한 것들이 있지만, 사람들이 기준을 설정한다고 생각하는 이러한 기본 단계 바로 위의 위치가 궁금합니다.

예를 들면 :

• 일반 사용자에게 사용하는 것과 동일한 인증 메커니즘에 의존하고 있습니까? 그렇지 않다면 무엇입니까?
• 동일한 '애플리케이션 도메인'에서 관리 섹션을 실행하고 있습니까?
• 관리 섹션을 발견하지 못하도록하기 위해 어떤 단계를 수행합니까? (또는 '모호함'전체를 거부합니까?)

---

지금까지 답변자의 제안은 다음과 같습니다.

• 무차별 대입 공격을 방지하기 위해 각 관리자 암호 확인에 인위적인 서버 측 일시 중지를 도입합니다. [개발자 아트]
• 동일한 DB 테이블을 사용하여 사용자와 관리자에 대해 별도의 로그인 페이지 사용 (관리 영역에 대한 액세스 권한을 부여하는 XSRF 및 세션 탈취 중지) [Thief Master]
• 또한 관리 영역에 웹 서버 네이티브 인증을 추가하는 것도 고려해보십시오 (예 : .htaccess를 통해) [Thief Master]
• 여러 번의 관리자 로그인 시도 실패 후 사용자 IP 차단 고려 [Thief Master]
• 관리자 로그인 시도 실패 후 보안 문자 추가 [도용자]
• 사용자와 관리자에게 똑같이 강력한 메커니즘 (위의 기술 사용)을 제공합니다 (예 : 관리자를 특별히 대하지 않음) [Lo'oris]
• 2 단계 인증 고려 (예 : 클라이언트 인증서, 스마트 카드, 카드 공간 등) [JoeGeeky]
• 신뢰할 수있는 IP / 도메인에서만 액세스를 허용하고 가능하면 기본 HTTP 파이프 라인 (예 : HttpModules를 통해)에 검사를 추가하십시오. [JoeGeeky]
• [ASP.NET] IPrincipal 및 Principal 잠그기 (불변 및 열거 불가능하게 만들기) [JoeGeeky]
• 권한 상승 연합-예를 들어 관리자의 권한이 업그레이드되면 다른 관리자에게 이메일을 보냅니다. [JoeGeeky]
• 관리자를위한 세분화 된 권한 고려-예를 들어 역할 기반 권한보다는 관리자 별 표시 작업에 대한 권한 정의 [JoeGeeky]
• 관리자 생성 제한-예를 들어 관리자는 다른 관리자 계정을 변경하거나 생성 할 수 없습니다. 이를 위해 잠긴 'superadmin'클라이언트를 사용하십시오. [JoeGeeky]
• 클라이언트 측 SSL 인증서 또는 RSA 유형 keyfob (전자 토큰) 고려 [Daniel Papasian]
• 인증을 위해 쿠키를 사용하는 경우 관리 페이지와 일반 페이지에 대해 별도의 쿠키를 사용하십시오 (예 : 다른 도메인에 관리 섹션을 배치). [다니엘 파파 시아]
• 가능하다면 관리 사이트를 공용 인터넷이 아닌 사설 서브넷에 유지하는 것이 좋습니다. [존 하트 삭]
• 웹 사이트의 관리자 / 정상 사용 컨텍스트간에 이동할 때 인증 / 세션 티켓 재발급 [Richard JP Le Guen]

---

이것들은 모두 좋은 대답입니다. 저는 일반적으로 관리 섹션에 대해 몇 가지 추가 레이어를 추가하는 것을 좋아합니다. 테마에 몇 가지 변형을 사용했지만 일반적으로 다음 중 하나가 포함됩니다.

• 2 단계 인증 : 여기에는 클라이언트 인증서 (예 : x509 인증서), 스마트 카드, 카드 공간 등이 포함될 수 있습니다.
• 도메인 / IP 제한 :이 경우 신뢰할 수있는 / 확인 가능한 도메인에서 오는 클라이언트 만; 내부 서브넷과 같은; 관리 영역에 허용됩니다. 원격 관리자는 종종 신뢰할 수있는 VPN 진입 점을 통과하므로 세션을 확인할 수 있고 종종 RSA 키로도 보호됩니다. ASP.NET을 사용하는 경우 HTTP 모듈을 통해 HTTP 파이프 라인에서 이러한 검사를 쉽게 수행 할 수 있습니다. 그러면 보안 검사가 충족되지 않을 경우 응용 프로그램이 요청을 수신하지 못합니다.
• 잠금 IPrincipal 및 Principal 기반 권한 부여 : 사용자 지정 원칙을 만드는 것은 일반적인 관행이지만 일반적인 실수는 수정 가능 및 / 또는 권한 열거 가능하게 만드는 것입니다. 단순한 관리자 문제는 아니지만 사용자가 높은 권한을 가질 가능성이있는 곳이기 때문에 더 중요합니다. 변경 불가능하고 열거 불가능한지 확인하십시오. 또한 승인에 대한 모든 평가가 교장을 기준으로하는지 확인하십시오.
• 권한 상승 연합 : 계정이 선택한 수의 권한을 받으면 모든 관리자와 보안 담당자에게 즉시 이메일로 통보됩니다. 이렇게하면 공격자가 권한을 높이면 즉시 알 수 있습니다. 이러한 권리는 일반적으로 권한이있는 권리, 개인 정보 보호 정보를 볼 수있는 권리 및 / 또는 금융 정보 (예 : 신용 카드)를 중심으로합니다.
• 관리자에게도 권한을 드물게 발행 : 마지막으로 일부 상점에서는 조금 더 발전 할 수 있습니다. 권한 부여 권한은 가능한 한 신중해야하며 실제 기능 동작을 포괄해야합니다. 일반적인 RBS (역할 기반 보안) 접근 방식은 그룹 정신 을 갖는 경향이 있습니다 . 보안 관점에서 이것은 최상의 패턴이 아닙니다. ' 사용자 관리자 '와 같은 ' 그룹 ' 대신 더 세분화하십시오 ( 예 : 사용자 생성, 사용자 권한 부여, 액세스 권한 상승 / 취소 등).). 이것은 관리 측면에서 약간 더 많은 오버 헤드를 가질 수 있지만 더 큰 관리자 그룹에 실제로 필요한 권한 만 할당 할 수있는 유연성을 제공합니다. 액세스가 적어도 손상되면 모든 권한을 얻지 못할 수 있습니다. 나는 이것을 .NET 및 Java에서 지원하는 CAS (Code Access Security) 권한으로 래핑하고 싶지만이 답변의 범위를 벗어납니다. 한 가지 더 ... 한 앱에서 관리자는 다른 관리자 계정을 변경하거나 사용자를 관리자로 만들 수 없습니다. 두 사람 만 액세스 할 수있는 잠긴 클라이언트를 통해서만 수행 할 수 있습니다.

---

웹 사이트에 일반 활동과 관리자 모두에 대한 로그인이 필요한 경우 (예 : 포럼) 동일한 사용자 데이터베이스를 사용하는 별도의 로그인을 사용합니다. 이렇게하면 XSRF 및 세션 탈취로 인해 공격자가 관리 영역에 액세스 할 수 없습니다.

Additionally, if the admin section is in a separate subdirectory, securing that one with the webserver's authentication (.htaccess in Apache for example) might be a good idea - then someone needs both that password and the user password.

Obscuring the admin path yields almost no security gain - if someone knows valid login data he's most likely also able to find out the path of the admin tool since he either phished it or keylogged you or got it via social engineering (which would probably reveal the path, too).

A brute-force protection like blocking the user's IP after 3 failed logins or requiring a CAPTCHA after a failed login (not for the first login as that's just extremely annoying for legit users) might also be useful.

---

• I reject obscurity
• Using two authentication systems instead of one is overkill
• The artificial pause between attempts should be done for users too
• Blocking IPs of failed attempts should be done for users too
• Strong passwords should be used by users too
• If you consider captchas ok, guess what, you could use them for users too

Yes, after writing it, I realize that this answer could be summarized as a "nothing special for the admin login, they are all security features that should be used for any login".

---

If you do use only a single login for users who have both normal-user privileges and admin privileges, regenerate their session identifier (be it in a cookie or a GET parameter or whatever...) when there is a change in the level of priviledge... at the very least.

So if I log in, do a bunch of normal user stuff and then visit an admin page, regenerate my session ID. If I then navigate away from an admin page(s) to a normal user page, regenerate my ID again.

---

Have a good admin password.

Not "123456" but a sequence of letters, digits and special characters long enough, say, 15-20 characters. Like "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".

Add a pause for each password check to prevent brute force attack.

---

Here are some other things to consider:

1. One option to consider, especially if you manage the admin's computers or they are technically competent, is to use something based on SSL certificates for client authentication. RSA keyfobs and whatnot can also be used for added security.
2. If you're using cookies at all - perhaps for an authentication/session token - you probably want to ensure that the cookies are only sent to the admin pages. This helps mitigate the risks posed to your site by stealing cookies, by either layer 1/2 compromise or XSS. This can be done easily by having the admin portion being on a different hostname or domain as well as setting the secure flag with the cookie.
3. Restricting by IP can be smart as well, and if you have users throughout the internet you can still do this, if there is a trusted VPN that they can join.

---

We use Windows Authentication for admin access. This is most practical way of protecting admin areas while keeping the authentication seperate from what applies to general end-users. The system admin manages the Admin user access credentials and enforces password policies on the domain user account.

---

The strict way is to have two complete different "farms" including databases, servers and all and move the data from one farm to the other. Most modern, large scale, systems use this approach (Vignette, SharePoint, etc.). It's normally refered to as having different stages "editing stage" -> "preview stage" -> "delivery stage". This method lets you treat content/config the same way you treat code (dev->qa->prod).

If you are less paranoid you can have a single database but only have your admin section available on the "editing" servers. I mean, only have the editing scripts/files placed on the editing server.

Naturally the editing stage should only be available on a local intranet and/or using a VPN.

This may seem a bit of an overkill and may not be the easiest solution for all usage cases, but it is definetly the most robust way of doing things.

Note that things like "have strong admin passwords" are nice, but still leave your admin open to smart attacts of all sorts.

---

It very much depends on what kind of data you want to protect (legal requirements and such).

• Alot of suggestions is about authentication.. I think you just should consider using OpenId / Facebook authentication as login. (They will most likely spend more resources on authentication security then you)

• Save changes as well as updating values in the database. That way you can rollback changes from user X or between date X and Y.

---

I didn't notice anyone mention storage/validation of the admin password. Please please please do not store the PW in plain text, and preferably not even something that can be reversed - use something like a salted MD5 hash so that at the very least if someone happens to retrieve the stored "password" they don't have anything terribly useful, unless they also have your salt scheme.

---

Add a password field and a security question that the Administrator will know, e.g. what was your first girlfriend name, or randomize the questions everytime viewing the admin panel.

Perhaps you could always put the administration section in a big directory, e.g.

http://domain.com/sub/sub/sub/sub/sub/index.php

But that's not really good hah.

Perhaps you could include a query string in the home page, like:

http://domain.com/index.php?display=true

When it does, the username and password field will appear.

참고URL : https://stackoverflow.com/questions/2848134/what-are-best-practices-for-securing-the-admin-section-of-a-website