SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 59
  1. #26
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samanime View Post
    Having a strong password is important (and maybe your user), but obfuscating your database name, tables, columns, etc., is a bad idea.
    I never said that, but having a directory called "admin" can't be a good idea either!


    Debbie

  2. #27
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samanime View Post
    I think there needs to be a distinction made here.

    You're probably thinking about things like a header.php which you include on every page, but it mostly contains HTML. These kinds of includes are perfectly valid being in your root directory. Depending on the size of the project I sometimes have it in the root (smaller), sometimes in a folder (larger).

    Stormrider is most likely talking about files which contain things like class definitions and what not. This are almost always in some other folder.

    (Apologizes if I'm off on my assumptions. =p)
    Okay, that makes sense. I never thought about things to that degree.

    Are there any set-backs?

    (Do you even have access outside of the Web Root on a VPS?)


    Debbie

  3. #28
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DoubleDee View Post
    It is one thing to know that debbie.png is in my "images" directory, but why advertise that "deathshadow.png" is also in there?
    Is it linked to from a page on the site? If the answer is no, what is it DOING there?

    Mind you, I saw that a lot cleaning up other people's messes (which is/was my specialty) where you'd see directories FULL of garbage that wasn't used ANYWHERE on the site -- mixed in with stuff that was.

    WHAT THE?!?!?

    Quote Originally Posted by DoubleDee View Post
    I don't follow you...
    All I can figure is you are talking about stuff that isn't actually used on the website in question -- if it's USED on the site the user can find it - PERIOD... that's what I'm saying... and why this:

    Quote Originally Posted by DoubleDee View Post
    I was simply proposing protecting people from casually walking through every directory and seeing everything in every directory.
    Makes me ask "Then why is it even ON the server in the first place?!?"

    Quote Originally Posted by DoubleDee View Post
    Really? Not from any security articles I have read when it comes to things like protecting database access, etc.
    That's what passwords are for -- knowing a table name, or subfunction name doesn't do you ANY good if you don't have permission to use it... and once they have permission to use it you aren't going to slow them down one bit with goofy naming schemes.

    At least if the code is written in ANYTHING resembling secure practices. As I have seen proven time and time and time and time and TIME again the past three decades, security through obscurity is no security at all. See BlackBerry at Pwn2Own.

    Quote Originally Posted by DoubleDee View Post
    I gotta hear an explanation on this one!

    What, you put *everything* in the Web Root?!
    Think before saying something like that... if you cannot link uptree or rooted, that means what direction can you go? DOWN-TREE.

    The three directory pathing methods:

    uptree: ../images/image.png -- /FAIL/

    rooted: /images/image.png -- /FAIL/

    downtree: images/image.png -- /WIN/

    1) Functions the user can call directly and/or static files in root; This is why I prefer to have a SINGLE index.php through which ALL functions are called... single valid .point of entry/exit means only one place they can hack.

    2) Subfunctions and things the user should not call directly for php in a subdirectory (like "sources" or "libraries"). Said files return NOTHING if called directly containing ONLY objects and functions. Secure functions (like returning SQL login info) I'll typically code to throw if they aren't called by the index.php in the directory above it. This also means NO global variables, no security information in DEFINE, etc, etc...

    Off Topic:

    Those two combined are where 90% (pulling a percentage out of my backside) of CMS have their gaping security holes.


    3) Content images (aka what should be in IMG tags) in a subdirectory so you can point DOWN-TREE. Likewise content files like downloads, movies, music can go in obviously named subdirectories down-tree of root.

    Code:
    <img
    	src="forums/images/lookAtMe.png"
    	alt="Yours Truly"
    />
    4) CSS and theme code can go in a nice easy directory named "themes" and you can even do easy multitheming with a subdirectory
    Code:
    <link
    	type="text/css"
    	rel="stylesheet"
    	href="themes/themename/screen.css"
    	media="screen,projection,tv"
    />
    5) images called by the CSS are (or should be) inherently presentational, tied to the skin... so put those in a subdirectory of where the CSS is located.
    Code:
    body {
    	background:#DEF url(themes/themename/images/bodyBackground.png) top center;
    }
    All pointing down tree -- markup calls css, images and scripts, so markup root, css images and scripts subdirectories. CSS calls images, put the ones that are CSS related under the CSS directory... in other words structure your page the same way it's called by the browser! -- such a radical concept; not.

    The moment you resort to rooting (/) or up-tree (../) you have to call your entire directory structure into question. Work WITH how the server and user agent works, not against it! Of course, I also filter ANY user input/value that might be translated into a directory to remove ../ on purpose, so as to prevent up-tree hacks (like the SMF/myBB/vBull avatar vulnerability from last year)

    ... and if it's NOT something that actually appearas on the website, what is it doing in a directory with stuff that is? Either put it in a subdirectory behind a password, in a subdirectory with a index.html to prevent dir listings, or just don't put it on the server in the first place.

    After all, the only reason to put files on a server is for people to get access to them... you don't want people seeing them, don't upload them.

    Of the four filetypes you listed, only "Includes" makes the LEAST bit of sense for what you are thinking; but frankly if those includes are written PROPERLY so they don't output anything when called directly -- by wrapping anything and EVERYTHING they do in functions or classes/methods -- and by not defining anything that could be mis-used, and adding a throw so only certain files can request secure information... The name of the directory or even their pulling a listing shouldn't matter.

    But again, there's a reason I'd like to see <?php and ?> removed from PHP completely...

  4. #29
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    I never said that, but having a directory called "admin" can't be a good idea either!
    Why? If you control your site from there, why make it hard to remember? Is crazyfuzzykittenz111a325 better? Sure, I can't guess it. But, if the site is secure and can't be hacked, what's it matter if they can see it?

    The problem with obfuscation, aside from the usability issue, is that it is often just a band-aid for not fixing other problems. It also makes it harder for other developers to work on it, for you to remember what's what, for you to be able to type it properly every time, etc.

    The cons greatly outweigh the pros in many situations.

    Okay, that makes sense. I never thought about things to that degree.

    Are there any set-backs?

    (Do you even have access outside of the Web Root on a VPS?)
    Depending on your file permissions, probably. Apache isn't bound to the web root, it is just restricted by it's user/group, just like any other user.

    There aren't any real setbacks, other than having to be a bit more careful with what you're doing (for example, if your FTP doesn't default to your web root, you have to make sure you change to your web root before you upload things). As long as you're organized, it's fine.

    Personally, I rarely keep mine OUTSIDE of the web root... for most things. There are a few things that I would (I just generally don't work on those types of projects). I usually keep mine in a folder inside the web root (though it generally has different permissions, like 700 or 770).

    A VPS is essentially the same as a dedicated server, in terms of what kind of control you have over it's insides, so yes, you do have access to it all. The key differences are just the obvious ones, that you don't have access to the hardware and the physical machine may be shared with other servers. Each server is essentially in it's own little pocket it can't break out of.

    -------

    I do want to give you a general word of caution when it comes to security.

    It is a very good idea to be well aware of this stuff, to actively think about it and understand how it all works.

    Security is good. So is organization... but there is a difference between keeping papers on your desk in a neat stack and keeping papers on your desk in a neat stack ordered alphabetically by the fourth letter on the page and the number of characters.

    There are things in security that are good to do always because they have very good return on the time invested. There are also things that have almost no return for a very large amount of time invested.

    Cleaning user input for SQL queries, making sure turning off Javascript doesn't break your site, etc., are all very good and should always be done.

    Things like setting up file permissions and what not are in between. Most of the time they don't have huge returns, but they don't take long so it's not bad to do it.

    Obfuscation is at the bottom of the barrel. It costs you a lot of time to do (when you consider how many times you have to type it, look it up, fix errors causes by it, etc.) and has only a very little return (keeps people from guessing).

    Just a little food for though.

  5. #30
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    deathshadow's tone could definitely use some work, but he has some valid points.

    About the web root, I think you guys are misunderstanding (and I actually misunderstood you as well, deathshadow). I think what Debbie though was you put all your files in your root directory directly (so, you'd have http://mysite.com/myimage.png, etc).

    I do agree that if there are images in your site that aren't being used, why are they there? However, at the same time, I do still support using -Indexes (which without may let them casually browse your directories). Going far beyond that is a bit pointless though because there shouldn't be anything non-public in there. Now, if it has secure documents or something, that is a different story, but then those wouldn't be accessible by the user anyways, so if you just pick a folder (with a reasonable name), who's gonna find it?

    I think 1 needs a bit of clarification (in case I'm reading it out how I think I am, which doesn't make sense). It sounds like you're saying all your functions go in index.php, which I doubt you're saying. You're saying all of your function calls should go in index.php, an branches out from there.

    So, for example, say you build a site using OOP. You have one main class called MySite. You'd call MySite in index.php, no matter which page you were on. You'd then use the functions in the class and what not to create other pages (with rewrites, etc.). I agree with this kind of single-starting-point approach.

    Absolutely agree with number 2, which are the kinds of files I think StormRider was talking about earlier. I think it's also a good idea to check if they should be there in some way, and if not, redirect them to the home page.

    3 is definitely a good idea. It's occasionally unavoidable, but 99% of the time it is easily done with proper planning.

    4 and 5 are debatable. Aside from Wordpress, I don't do many skinnable projects, so I like to keep my images all in one place (unless it is a huge number). However, there are definitely advantages the the approach deathshadow talks about as well. I think this is personal preference.

  6. #31
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samanime View Post
    deathshadow's tone could definitely use some work, but he has some valid points.I do agree that if there are images in your site that aren't being used, why are they there? However, at the same time, I do still support using -Indexes (which without may let them casually browse your directories).
    As do I -- usually it's not because of security for me so much as it is

    Though they've become a non-issue since every site I've written the past five years has this .htaccess:

    Code:
    RewriteEngine On
    RewriteRule !\.(gif|jpg|png|css|js|swf|html|ico|zip|rar|pdf|xml|mp4|mpg|flv|mkv)$ index.php
    Since any request off the root directory of the site that isn't a direct link to one of those filetypes is FORCED through the CMS. So much for browsing

    Quote Originally Posted by samanime View Post
    I think 1 needs a bit of clarification (in case I'm reading it out how I think I am, which doesn't make sense). It sounds like you're saying all your functions go in index.php, which I doubt you're saying. You're saying all of your function calls should go in index.php, an branches out from there.
    Correct -- I'm not even sure where you're getting that I was saying dump it all in root -- Oh, you're confusing function php's with function CALLS and DECLARATIONS -- there's a difference. See how I said "function php's" -- user functions; stuff the user can call directly via the URL as a separate file... Which I don't actually HAVE anymore on anything I've written after 2006. Basically I was referring to the half-assed coding approach of systems like myBB or phpBB where every 'function' has it's own php file the user calls directly -- I hate that.

    Off Topic:


    But then I don't get a lot of where people misunderstand me online -- Like where people have a problem with my tone either; It's like people have never worked in a business or something.

    But I say the same thing given how people react to Simon Cowell and Gordon Ramsey. They behave like every REAL professional businessman I've ever dealt with.


    Quote Originally Posted by samanime View Post
    So, for example, say you build a site using OOP. You have one main class called MySite. You'd call MySite in index.php, no matter which page you were on. You'd then use the functions in the class and what not to create other pages (with rewrites, etc.). I agree with this kind of single-starting-point approach.
    While I'd not waste the overhead of a class/object on the outermost handler -- and due to my adding functions based solely on what the user called for a function objects are not extensible enough (in php) for me to use that approach, yes, that's the general idea.

    But then, I don't just slap objects on things because it's trendy... I use them when they are appropriate like when there's going to be more than ONE instance or secure data is being handled -- which in php typically means a PDO object and... well, that's about it. (since 99% of the stuff I'd actually use objects for is handled by the SQL server)

    Quote Originally Posted by samanime View Post
    Absolutely agree with number 2, which are the kinds of files I think StormRider was talking about earlier. I think it's also a good idea to check if they should be there in some way, and if not, redirect them to the home page.
    That's why I'm using that .htaccess above -- except for files with those extensions, send EVERY other request be it a directory or file through the index.php and let it do the error handling. Also lets me do styled 404's that match the rest of the site layout since I can still call the theme.

    Quote Originally Posted by samanime View Post
    3 is definitely a good idea. It's occasionally unavoidable, but 99% of the time it is easily done with proper planning.
    Only time I've found it unavoidable is when cleaning up some mess somebody else wrote. If you plan it properly from the start with clearly defined roles for what goes where, it should be a non-issue. You sleaze together a site using some garbage off the shelf solution, YMMV.

    Quote Originally Posted by samanime View Post
    4 and 5 are debatable. Aside from Wordpress, I don't do many skinnable projects, so I like to keep my images all in one place (unless it is a huge number).
    Even if it's single theme and I'm creating a new system, I'd use theme/screen.css and theme/images/bodyBackground.png (for example) removing the theme name. It's just nice to keep it separated and it helps with the directory linking.

    While yes, it's a personal preference, it's also good organization. I can't stand it when you see a directory of a few hundred images slapped together that are a mix of theme and content images. The more you organize your files in a clean consistent manner and establish clear-cut easy to follow roles for directories, the easier it is to maintain. Basically it's applying to the directory structure the same old rules that are used for building an application. (Not that it seems anyone knows or has been taught those rules after about 2002)

    Mostly it's about using one of the best features of how a user agent reads a page to your advantage -- if you omit any sort of leading slashes any directory access from the html is automatically treated as where that HTML file was accessed from. If you do the same in a CSS file, all accesses treat the location of that CSS file as the current location...

    Oh, and there's a typo in my last post, the directory for the CSS version is wrong. Should be:

    background:url(images/bodyBackground.png);

    Which will point at "theme/themename/images/bodyBackground.png" so long as the css file in question is in "theme/themename"...

    My bad.

  7. #32
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    Just to clarify, I understood what you meant... it's just how it sounded when I first read it, it screamed confusion for others, so I wanted to add an example. =p I definitely agree with you. Unfortunately I have to work with vBulletin on a near daily basis and it drives it nuts.

    I also don't throw together an object for everything either... it was just the quickest, clearest way for me to explain the separation of functions.

    I can see why you like using a "theme" structure. I agree that it's annoying to have a billion images in one folder all thrown together. I didn't think of your approach in those terms at first, because my "images" folder almost always contains just design images (some are used as images, but they're still mostly decoration). Things like image galleries, icons, attachments, etc. always get their own folders.

    Of course, my approach does mean I use ../, which I know isn't ideal, but I still like it. =p It is actually the first time I've seen your approach though, and I must say, it's not a bad idea. I doubt I'll adopt it any time soon, but I'm sure I'll keep it in mind.

  8. #33
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samanime View Post
    I think there needs to be a distinction made here.

    You're probably thinking about things like a header.php which you include on every page, but it mostly contains HTML. These kinds of includes are perfectly valid being in your root directory. Depending on the size of the project I sometimes have it in the root (smaller), sometimes in a folder (larger).

    Stormrider is most likely talking about files which contain things like class definitions and what not. This are almost always in some other folder.

    (Apologizes if I'm off on my assumptions. =p)
    It is what I meant, yes, although in my projects just about everything except index.php, and the static assets (js, css, images) live outside the web root anyway!

  9. #34
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    uptree: ../images/image.png -- /FAIL/
    I can't WAIT to hear the explanation for this one :P

    Absolute paths (or 'rooted' as you call them) are a fail, but nothing wrong with the above. It's still a method of relative linking, no different to 'down tree' linking as you are calling it in terms of issues.

  10. #35
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Off Topic:

    Also lets me do styled 404's that match the rest of the site layout since I can still call the theme.
    I am thoroughly surprised that there ISN'T a valid page on Crusty's sites called whisky tango foxtrot : )


    Quote Originally Posted by DD
    For instance, maybe I don't want you downloading all of my images, content, etc. Then preventing people from seeing what is in a directory cannot hurt.
    Meh.
    wget -r --no-parent -A png,"jpe?g",gif http://your-website.com/images/

    Though I can also just ask for everything in that folder if I think they are just image files.

    My point only being that stopping ppl from seeing what's in a dir has little bearing on whether they want to copy from it (and then they see it, no?). I'm not disagreeing with it not being a bad thing to remove indexes and use DirectoryIndex in Apache.

  11. #36
    SitePoint Wizard rguy84's Avatar
    Join Date
    Sep 2005
    Location
    Durham, NC
    Posts
    1,659
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)
    Poes You may want to explain wget for debbie.

    ds60 your linking names made me scratch my head. I never heard them referred to that way.
    Ryan B | My Blog | Twitter

  12. #37
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    That's because they aren't referred to in that way. There is absolute linking and relative linking. 'up-tree' and 'down-tree' as DS calls them are equivalent (no difference at all), and are both forms of relative linking. Starting with a / would be absolute linking.

  13. #38
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Starting with a / would be absolute linking.
    Might be off-topic but the way my husband sets things up, everything looks like it's from root (so the main page/default is "/" and everything starts with /) but it isn't really. It's some kind of fakery set up in the back end. It's always confused me why and how, but so just saying that seeing urls start with / in the source isn't necessarily what it seems.

    Off Topic:


    Poes You may want to explain wget for debbie.
    ok
    wget is a tool that comes standard on all work computers (computers built to do actual computery-stuff). It's basically a user agent (a browser is also a user agent) you can control from the command line to grab stuff (documents, files) from the web and save them locally (actually, it can also just spider things... check that the files are there but not copy).
    What's nice/useful about it is you can grab whole groups of files at once, and preserve their hierarchy (if you're trying to make a copy of a site, you can keep all the associated files in relatively the same place, meaning when you view the files locally, links, images, styles and scripts should all work just as if you had built it locally... not sure about sites who use absolute (http:// starting) links for everything like Wordpress tho).

    *edit I 'spose I should mention there are other tools that do similar, like cURL (comes on Macs instead of wget I think)

  14. #39
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Yeh, indeed. I usually set a <base href> then all my URLs in the HTML are just set relative to that URL. The base url value is controlled with a config file.

    CSS background images etc have to use ../images/image.jpg etc in the urls, because you have to jump out of the css directory then into the images one. This is still relative linking and will still work if you move the site to another directory.

  15. #40
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    I have officially protested the use of the base element. =p vBulletin absolutely abuses it for all of their scripts, which completely destroys jump links. I couldn't just remove the base element because of their reliance on it, so I had to add Javascript to make jump links work.... seriously.... =(

  16. #41
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Ah yeh, you have to be careful with that, but it's easily the best solution for an application that uses rewritten urls - either that or use absolute paths, which is worse I think.

  17. #42
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    Is it linked to from a page on the site? If the answer is no, what is it DOING there?

    Mind you, I saw that a lot cleaning up other people's messes (which is/was my specialty) where you'd see directories FULL of garbage that wasn't used ANYWHERE on the site -- mixed in with stuff that was.

    WHAT THE?!?!?
    No, I would expect everything in my web root to be active.

    I was just saying I make it overly easy for people to see all of your files.


    Quote Originally Posted by DoubleDee
    Really? Not from any security articles I have read when it comes to things like protecting database access, etc.
    That's what passwords are for -- knowing a table name, or subfunction name doesn't do you ANY good if you don't have permission to use it... and once they have permission to use it you aren't going to slow them down one bit with goofy naming schemes.
    I never said using goofy names for database components, but it does make sense to not store everything in default folder names in default places.

    People who do "drive-by" attacks tend to look in obvious places for obvious weaknesses.

    If you makes things a little more obscure, it may make them keep going.

    However, I have never said that is a total security solution.

    I have just read enough *valid* security articles to know that this is one of numerous strategies that should up decrease your chances of being hacked.


    At least if the code is written in ANYTHING resembling secure practices. As I have seen proven time and time and time and time and TIME again the past three decades, security through obscurity is no security at all. See BlackBerry at Pwn2Own.
    But it is one of 100 things - that when combined together - can help.


    Quote Originally Posted by DoubleDee
    I gotta hear an explanation on this one!

    What, you put *everything* in the Web Root?!
    Think before saying something like that... if you cannot link uptree or rooted, that means what direction can you go? DOWN-TREE.
    You most certainly can "include" files outside of your Web Root...

    Off Topic:

    I was up until 4:00am I apologize, but a lot of points we were arguing on are probably lost, because of the Internet and Time and my 4am *computer* hang-over!



    The three directory pathing methods:

    uptree: ../images/image.png -- /FAIL/

    rooted: /images/image.png -- /FAIL/

    downtree: images/image.png -- /WIN/

    1) Functions the user can call directly and/or static files in root; This is why I prefer to have a SINGLE index.php through which ALL functions are called... single valid .point of entry/exit means only one place they can hack.
    I don't disagree.


    2) Subfunctions and things the user should not call directly for php in a subdirectory (like "sources" or "libraries"). Said files return NOTHING if called directly containing ONLY objects and functions. Secure functions (like returning SQL login info) I'll typically code to throw if they aren't called by the index.php in the directory above it. This also means NO global variables, no security information in DEFINE, etc, etc...
    Someone else said put important PHP stuff outside of Root. Makes sense to me.


    Off Topic:

    Those two combined are where 90% (pulling a percentage out of my backside) of CMS have their gaping security holes.
    I'm sorry, but again, the continuity of our conversation is dying due to no fault of our own.

    Recap.

    What are CMS's two fatal flaws?


    3) Content images (aka what should be in IMG tags) in a subdirectory so you can point DOWN-TREE. Likewise content files like downloads, movies, music can go in obviously named subdirectories down-tree of root.
    Right. I was just saying maybe change the name from "images" to something slightly more obscure like "profile_pics".

    I dunno.


    4) CSS and theme code can go in a nice easy directory named "themes" and you can even do easy multitheming with a subdirectory
    I thought you said before you don't use directories/sub-directories?



    The moment you resort to rooting (/) or up-tree (../) you have to call your entire directory structure into question. Work WITH how the server and user agent works, not against it!
    I never implied that for page content, but what about the suggestion of "hiding" things like PHP classes or Data Config stuff outside of Root?


    ... and if it's NOT something that actually appearas on the website, what is it doing in a directory with stuff that is?
    I don't disagree.


    Either put it in a subdirectory behind a password,
    So you agree with that?


    in a subdirectory with a index.html to prevent dir listings,
    Or can you do the "Not Indexed" thing mentioned previously?


    or just don't put it on the server in the first place.
    I got that.


    Of the four filetypes you listed, only "Includes" makes the LEAST bit of sense for what you are thinking; but frankly if those includes are written PROPERLY so they don't output anything when called directly -- by wrapping anything and EVERYTHING they do in functions or classes/methods -- and by not defining anything that could be mis-used, and adding a throw so only certain files can request secure information... The name of the directory or even their pulling a listing shouldn't matter.
    Fair enough.


    But again, there's a reason I'd like to see <?php and ?> removed from PHP completely...
    And that reason would be???


    Debbie

    P.S. Feel free to provide your thoughts and feeling on my other security thread Virtual Private Server (VPS) security That is a place I could definitely use some expert advice!

  18. #43
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samanime View Post
    I do want to give you a general word of caution when it comes to security.

    It is a very good idea to be well aware of this stuff, to actively think about it and understand how it all works.

    Security is good. So is organization... but there is a difference between keeping papers on your desk in a neat stack and keeping papers on your desk in a neat stack ordered alphabetically by the fourth letter on the page and the number of characters.

    There are things in security that are good to do always because they have very good return on the time invested. There are also things that have almost no return for a very large amount of time invested.

    Cleaning user input for SQL queries, making sure turning off Javascript doesn't break your site, etc., are all very good and should always be done.

    Things like setting up file permissions and what not are in between. Most of the time they don't have huge returns, but they don't take long so it's not bad to do it.

    Obfuscation is at the bottom of the barrel. It costs you a lot of time to do (when you consider how many times you have to type it, look it up, fix errors causes by it, etc.) and has only a very little return (keeps people from guessing).

    Just a little food for though.
    I don't disagree with anything you said above.



    Debbie

  19. #44
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samanime View Post
    deathshadow's tone could definitely use some work, but he has some valid points.

    About the web root, I think you guys are misunderstanding (and I actually misunderstood you as well, deathshadow). I think what Debbie though was you put all your files in your root directory directly (so, you'd have http://mysite.com/myimage.png, etc).
    Yes, that is what I thought he was saying.

    And what was he proposing?


    Now, if it has secure documents or something, that is a different story, but then those wouldn't be accessible by the user anyways, so if you just pick a folder (with a reasonable name), who's gonna find it?
    So let's say I have articles or images that are for "preferred" customers. They aren't technically being used/relevant to a lot of users, but they are still sitting out there for a select few. So that is an example of the bigger picture of my deserve to hide, obscure and protect from casual browsing.


    Debbie

  20. #45
    SitePoint Wizard DoubleDee's Avatar
    Join Date
    Aug 2010
    Location
    Arizona
    Posts
    3,777
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Gee, you guys sure came out of the woodwork at an inopportune time! (Gang tackling poor Debbie after an all-nighter!)

    Most of this thread is over my head or not relevant, but still somewhat interesting.

    At least it will help others out.

    Where are my Tylenol?!


    Debbie

  21. #46
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    Yes, that is what I thought he was saying.

    And what was he proposing?
    He's proposing his theme approach. He's saying if you make a whole folder just for css (which should contain at most only a small handful of files), you may want to reconsider things.

    I personally disagree with him on this, but I see his point.

    So let's say I have articles or images that are for "preferred" customers. They aren't technically being used/relevant to a lot of users, but they are still sitting out there for a select few. So that is an example of the bigger picture of my deserve to hide, obscure and protect from casual browsing.
    I would put those in a different section entirely. Just like how if I create an admin section, anything related to the admin section lives within those folders.

    I'd create some kind of control panel section in which all of the files only viewable at that level live.

  22. #47
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Stormrider View Post
    That's because they aren't referred to in that way. There is absolute linking and relative linking. 'up-tree' and 'down-tree' as DS calls them are equivalent (no difference at all), and are both forms of relative linking. Starting with a / would be absolute linking.
    Sorry, but I'm used to seeing them referred to that way for oh say... thirty years.

    Since that's what it's called when working from the command line or in a real programming language... Though I always argued that up and down were reveresed on that, since down should take you closer to the root; but it refers to how programs like DOS Tree, Commander or XTree displayed the filesystem tree, with root at the top and the branches going down. Up-tree referred to going up that tree list, down-tree, well...





    But again, I'm the guy who looks at the default behavior of current filesystems and screams "Oh for crying out loud, just show me the damned filesystem tree!" (at least windows can be set to default to that - feel like ripping my hair out when I'm stuck on the crippleware of Linsux and OSuX... well, more like OSuX since at least on Linux there's ZTree)-- really sad when todays file management software isn't as capable or complete as a DOS application from 1985.

    Another of those things that it seems isn't being taught and/or isn't being learned by programmers of the past few years; like all the good lessons of what was considered computer basics 101 a decade ago have been thrown in the trash... lessons like don't let library files in a scripting language output anything... lessons like globals and defines should never be used for security information... lessons like how to use a filesystem tree efficiently... lessons like what chmod is, how to use it, and that leaving your #1 security file or even ANY file in the system 777, 666 or even 755 is a REALLY BAD IDEA.

    (Since it often seems EVERY CMS and forum software wants you to do that these days... and that's not just WP I'm ragging on for that -- see SMF, phpBB and vBull)

  23. #48
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,278
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Off Topic:

    But again, I'm the guy who looks at the default behavior of current filesystems and screams "Oh for crying out loud, just show me the damned filesystem tree!" (at least windows can be set to default to that - feel like ripping my hair out when I'm stuck on the crippleware of Linsux and OSuX..
    Maybe because command-line cowboys don't need to "see a tree". People who do, use GUIs it seems.
    Which is why the "menu system" of the text browser Elinks always makes me laugh... it imitates a graphical browser dropdown... in the terminal.

  24. #49
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Off Topic:

    Quote Originally Posted by Stomme poes View Post
    Maybe because command-line cowboys don't need to "see a tree". People who do, use GUIs it seems.
    So... no midnight commander or ztree for you?

  25. #50
    SitePoint Guru Jason__C's Avatar
    Join Date
    Oct 2009
    Location
    Racoon City
    Posts
    660
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Folder/File Security is simple in .NET. We use a web.config file. You PHP people are missing out.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •