PHP5 CMS Framework Development;

Podstrony

[ Pobierz całość w formacie PDF ]
.The weaknesses tend to come from apparently less critical code.Maybe some partof the CMS lists out information.If SQL injection is permitted, the request to thedatabase can be subverted to list out the user passwords instead of the intendeddata.Even if the CMS itself is highly robust and all user input is being checked (if the CMS permits extensions to be added) there is the possibility of weaker code allowingSQL injection exploits.Nothing can totally solve problems of this kind, but the more hurdles we can put inthe way, the more secure our system.One way to harden a CMS is to split the storeddata into two databases, both handled by the same database system.Critical datathat affects the basic operation of the CMS goes into a core database while everythingelse is placed into a general database.Extensions normally use only the generaldatabase.The two databases have different users, with each user having access toonly one database.Inevitably, this scheme could in some circumstances be subverted.But it createsanother barrier so that the amount of framework code that is vulnerable to aSQL injection attack is greatly reduced.In particular, the potentially less reliableextensions are not normally able to access the critical data.Naturally we will keepdetails of user passwords, salts, and activation codes in the core database.[ 33 ]Administrators, Users, and GuestsLoginClearly we need to have a mechanism whereby users identify themselves and arerecognized.This is what login is all about.Once a user has been authenticated,we must keep track of them, in the sense of knowing that requests come from anidentified user.Having opted to put some critical functions into a distinct administrator interface,we need to distinguish between the administrator login, and the general user login.Apart from offering quite separate ranges of services, there is a difference in the kindof continuity required.It makes no sense to talk about administrator actions prior tologin, since all administrator actions require login.Outside the closed administratorarea things are different.For example, it is common to allow a guest to browse a siteand add items to a shopping cart, only requiring some form of login when checkoutis requested.So for the non-administrator case, there is a need for continuity before,during, and after login.Apart from this distinction, there is an obvious need to be able to tie informationto the authenticated user in both cases.Since the web uses a connectionlessprotocol, we need a mechanism that gives us the continuity that is needed.Theobvious one to use is the PHP sessions capability.Each request makes a call toPHP for session_start(), which activates a cookie-based mechanism formaintaining continuity.Remember that we rejected the URI-based alternative as one of our basicdesign choices in Chapter 1, more about the same has been discussed inChapter 4.Information stored in the $_SESSION super-global is retained across requests.Wehave an immediate need to store the details of who has logged in, so that successiverequests can be geared to the characteristics of the identified user.There is more tousing sessions than this brief paragraph describes, as we need to secure ourselvesagainst the vulnerabilities of session hijacking, and session fixation.Also, there areconsiderations of scalability, and efficiency.Session management is covered in muchmore detail in a later chapter.Managing User DataSuppose the decision has been made to allow more users who can log in to thesystem than just the default administrator.The least we need is software to allowan administrator to add, update, or delete user information.Using the extensionterminology introduced in Chapter 1, we need a component for user management.[ 34 ]Chapter 2It may be that we would want to provide some "self service" features to users, but it is not a good idea to include that in the same component on account of our designprinciple of installing only the software that is actually needed.It is easy to envisage circumstances where user administration is required but self service is not, so it isbetter to implement two separate components.The user management component is,therefore, purely to provide a service for use by administrators.To some extent, user management is a simple database update problem.But ithas been made harder by the decision to place critical tables in a different databasefrom general tables [ Pobierz całość w formacie PDF ]

zanotowane.pl

doc.pisz.pl

pdf.pisz.pl

bezglutenowo.pev.pl