While that is true, it is very common for vulnerable websites to have JS injected in their databases via SQL injection.
If I have, let say, a custom homegrown CMS...obviously there's going to be some JS and HTML in my data store (unless I store everything as physical files. Uncommon). So I can't exactly escape my output, since valid javascript IS the output... Compromise the database, and the whole thing is compromised.
Yes, the 3D in the 3DS can be disabled. Besides, it works by showing different images at different angles, not 2 images that are somehow polarized, so if only one of your eyes sees anything, you wont see the other image at all, thus it shouldn't bother you. Not only can the 3D be disabled, it can be adjusted (via slider).
Anyhow, of course visual things can't be experienced by everyone. A whole lot of people are color blind... doesn't mean we should make games in black and white =P
Job where you're not working as a dumb code monkey and where the design of the application is more complex than its implementation. With modern tools and languages, an entire application can be a few hundred or thousand lines of code top. Getting the business requirements, the look & feel and design right can still take months. End result: i have weeks where I'll write maybe 10 lines a day.
Agreed. Like i said...the OOP constructs are good, and you can use them the same way you use functions or control blocks, without falling in the whole OOP ivory tower. You don't need a professor to spend a semester to help you do that.
The constructs are good. The methodology is bad. No point going further than that. From the sound of it, you agree with me, I'm just expressing myself poorly.
OOP and language constructs that allow it are 2 things.
There's nothing wrong with using objects, methods, inheritance (ok, there's a lot wrong with this one...), polymorphism, etc, to make your code clean, to wrap logic, to make modules, and so on.
There's a whole lot wrong with the OOP concept and methodologies. Modeling business entities as classes, encapsulating behavior in those entities, and so on. It quickly makes your applications unmaintainable, no one understands it, its almost inevitably slow by design, and the software architects from the Ivory Tower keep calling shots that make it worse and worse.
You don't need a course dedicated on showing you how to use the language constructs. You'd only need a course dedicated to OOP if you were to teach the whole theory and how to model stuff with the language constructs. End result: you can just drop it. CMU still gives you the choice of an elective if you really want to learn what NOT to do.
IE won't do that for various reasons. Most windows client admins want this behavior because they want to control the rollout. That is part of the diversity...in some sense IE is a better option in large corporate environments and a worse one for individuals at home...aside from the standards stuff...from the purse install\app standpoint. If you don't work as a client admin for a firm of 10,000+ you might not get this and even if you do you won't want to admit it:).
Chrome is starting to go that way too. Its beggining to have the corporate features IE was so popular by sysadmins for, and a Google Apps subscription now doubles as a support contract for Chrome in the enterprise. So sysadmins can control deployments, can use domain policies, etc, with Chrome.
Bonus points: Chrome supports windows auth out of the box (Firefox does too with a tweak in the about:config I guess)
You have to be careful though. You basically would need 2 domains or something. (its late, so correct me if I'm forgetting something stupid).
The tokens have to be carried around by the client SOMEHOW. On the web, thats hidden field, javascript variable, or cookie.
If you go all out ajax and only send the token with the appropriate requests, you're good. Javascript-only though.
Otherwise, you have to post the hidden field from page to page, or even worse, the cookie will do so all the time automatically for the domain. Send the "super secure cookie" once on a non-https page and its over.
Alternatively, on the non-https site, keep in mind that the whole thing is fair game to a man in the middle... so tricking the user into taking an action that will send their token to the wrong page would be relatively simple.
Not saying it can't be done, or that its a bad idea... but the increased audit you'll have to do on your code will cost you more than getting an SSL accelerator appliance and just hooking it up, and turning on SSL across the board.
For small sites, even my ultra-budget shared web host and VPS have enough power to SSL everything at all time, with a fair amount of hits per day.
For big sites, the cost of an appliance will be minimal compared to the big picture. So yeah...it can be done. But why? (note: Im sure there are some very very thin edge cases, if you're called Amazon, Google, or Ebay. But those are edge cases about everything)
[blockquote]I would have hard a time recommending to anyone to run their whole site in SSL. Get the logins or most forms in SSL, but the rest would be overkill.[/blockquote]
While most of your post is correct, not that part. Encrypting the login without encrypting the rest of the session is virtually completely pointless, since you leave your users vulnerable to session replay attacks. Yay, I don't know your password! Who cares, I have your authentication token.
Thats weird. I'm using chrome as my primary browser and for development (until i need firebug anyway. I dislike the Chrome dev tool), and my web app, with douzans of javascript files and hundreds of small images (nothing's combined or minified while I develop), when i hit refresh, loads up in less than a second.
Thats a "one page loads everything ahead of time and use javascript for everything" kind of app, so there's a LOT of files being loaded (far more than a standard web page, by a few orders of magnitudes), and its using windows authentication even for the images (during development only obviously), so caching is disabled across the board.
It works perfectly well for "small" tasks like this too. My netbook that i use everyday, with Aero on, to do everything except gaming and software development is on 1 GB. You do NOT need 2 GB for small tasks.
And yet, when they refuse to give primary support to stuff thats just a few years younger (the bullshit that is Windows XP), people go batshit insane on these very forums...
Microsoft has pretty strict support timelines for each of their products, provided up front, and, rightly so, stick to them.
So they'll stop supporting IE6 when all the products that requires it are out of their support time frame. (I think all of the relevent ones are in extended support now? So almost done)
My approach to every project is "use the right tool for the right job".
For public facing websites, the right tool will almost always be a CMS.
For the rest, it depends: for internal web app my personal favorite is usually a composite application framework. Unfortunately, unlike CMSs, there are very few of those, and the ones that do exist tend to be immature, so I had to write my own. Some internal web app projects are suitable for CMS too though.
If when you think CMS you think "biiiiiiiiiiiiiiiiiiig", you haven't looked at the good ones (ok, aside SiteCore: that thing is a behemoth, but it IS really awesome, as I mentionned before =P)
If, in this day and age, you're making a website from scratch, you're doing it WRONG. Exception only for specialized web applications that try to do "thick client" stuff on the web (let say something like gmail).
For normal public facing sites, or intranets, if you don't use a CMS, you'll have to replicate basic stuff for nothing. Sure, stuff like ASP.NET or PHP/Ruby/Python/Whatever frameworks will handle low level authentication, data access, navigation and whatsnot, but a CMS will give you a working web sites, with all that already in a working state, and you just need to add your styles, template, and business-specific logic and you're done.
Being a.NET dev, I use Umbraco (the best one is SiteCore by a landslide, and not just if you're a.NET dev...its just impossibly expensive. Worth it if you can afford it though). It handles all the stuff thats common to all websites, and not an inch more. Then doing anything "from scratch" that would take a few hours or days takes a few minutes, and you're not stuck with precanned impossible to modify garbage like some other major CMS will force on you: everything is easy to modify.
There's a million CMS out there in all flavors that offer all level of abstractions and specialization, depending on your requirement. Pick one, and stop wasting your time doing garbage from scratch.
The very reason there IS a mysql_real_escape_string is one of the more well known occurance of what Im talking about. There was another case with Oracle about 2 years ago. Escape functions are unreliable.
And you can just dynamically create the SQL with concatenation, as long as the source of the data is trusted, and you use parameters, thus how you can do a prepared statements to do it: again, all good ORMs do it like this to deal with databases without a decent pivot function/facility.
You can still dynamically generate prepared statements. Thats how ORMs do it. Most RDBMs will even let you dynamically generate a prepared statement and call it within a stored procedure.
There's nothing mythical about it: escaping still sends a string to the database, and relies on the conversion algorithms of it to deal the values. Every so often, as more research is done in vulnerabilities of string encodings and whatsnots, people find ways to confuse the engines with some really screwed up strings. Its not magic: the attack surface area is just waaaaaaaaay bigger, since you're letting your application layer guess the behavior of the database, so any change to either side, and boom! Or do you think SQL injection is just about sneaking a second command to the first one by adding --,;, or whatever terminator the database uses, like what most script kiddy attacks do?
Yup. It doesnt help that most samples you'll find online normally show the "easy quick way" of doing things, and often its the wrong way.
I'm an ASP.NET developer myself. ASP.NET has two "main" ways of working: WebForm (old), and MVC (new).
The MVC way has very good samples that generally show best practices. WebForm is technically superior in a lot of ways, but 99.999% of examples online show HORRILE HORRIBLE ways of using it.
Thus, virtually all WebForm code I've touched over a decade has sucked balls. Think worse than bad PHP code kindda sucked.
There's zero reasons for it to be that way: the "easiest" way of doing everything is actually the correct way. But all examples you'll find, all the blog posts, even huge commercial apps (SharePoint comes to mind, and its made by Microsoft itself!!) does it the wrong way according to the WebForm best practices.
Slashdot Mirror
While that is true, it is very common for vulnerable websites to have JS injected in their databases via SQL injection.
If I have, let say, a custom homegrown CMS...obviously there's going to be some JS and HTML in my data store (unless I store everything as physical files. Uncommon). So I can't exactly escape my output, since valid javascript IS the output... Compromise the database, and the whole thing is compromised.
You mean like this?
http://office365.microsoft.com/en-US/online-services.aspx
The whole publishing/CMS/business intelligence/groupware/database stack in the cloud. Not -exactly- what you meant...but freagin close.
Yes, the 3D in the 3DS can be disabled. Besides, it works by showing different images at different angles, not 2 images that are somehow polarized, so if only one of your eyes sees anything, you wont see the other image at all, thus it shouldn't bother you. Not only can the 3D be disabled, it can be adjusted (via slider).
Anyhow, of course visual things can't be experienced by everyone. A whole lot of people are color blind... doesn't mean we should make games in black and white =P
Job where you're not working as a dumb code monkey and where the design of the application is more complex than its implementation. With modern tools and languages, an entire application can be a few hundred or thousand lines of code top. Getting the business requirements, the look & feel and design right can still take months. End result: i have weeks where I'll write maybe 10 lines a day.
Agreed. Like i said...the OOP constructs are good, and you can use them the same way you use functions or control blocks, without falling in the whole OOP ivory tower. You don't need a professor to spend a semester to help you do that.
The constructs are good. The methodology is bad. No point going further than that. From the sound of it, you agree with me, I'm just expressing myself poorly.
OOP and language constructs that allow it are 2 things.
There's nothing wrong with using objects, methods, inheritance (ok, there's a lot wrong with this one...), polymorphism, etc, to make your code clean, to wrap logic, to make modules, and so on.
There's a whole lot wrong with the OOP concept and methodologies. Modeling business entities as classes, encapsulating behavior in those entities, and so on. It quickly makes your applications unmaintainable, no one understands it, its almost inevitably slow by design, and the software architects from the Ivory Tower keep calling shots that make it worse and worse.
You don't need a course dedicated on showing you how to use the language constructs. You'd only need a course dedicated to OOP if you were to teach the whole theory and how to model stuff with the language constructs. End result: you can just drop it. CMU still gives you the choice of an elective if you really want to learn what NOT to do.
Thanks for the 10th grade (if that) science lesson. Too bad you missed out on the critical thinking lessons.
666000 still gets the point across. An article isn't a scientific document and doesn't pretend to be.
What do you mean by auto-login like IE? integrated auth? Chrome does support that. Or do you mean something else?
Chrome is starting to go that way too. Its beggining to have the corporate features IE was so popular by sysadmins for, and a Google Apps subscription now doubles as a support contract for Chrome in the enterprise. So sysadmins can control deployments, can use domain policies, etc, with Chrome.
Bonus points: Chrome supports windows auth out of the box (Firefox does too with a tweak in the about:config I guess)
You have to be careful though. You basically would need 2 domains or something. (its late, so correct me if I'm forgetting something stupid).
The tokens have to be carried around by the client SOMEHOW. On the web, thats hidden field, javascript variable, or cookie.
If you go all out ajax and only send the token with the appropriate requests, you're good. Javascript-only though.
Otherwise, you have to post the hidden field from page to page, or even worse, the cookie will do so all the time automatically for the domain. Send the "super secure cookie" once on a non-https page and its over.
Alternatively, on the non-https site, keep in mind that the whole thing is fair game to a man in the middle... so tricking the user into taking an action that will send their token to the wrong page would be relatively simple.
Not saying it can't be done, or that its a bad idea... but the increased audit you'll have to do on your code will cost you more than getting an SSL accelerator appliance and just hooking it up, and turning on SSL across the board.
For small sites, even my ultra-budget shared web host and VPS have enough power to SSL everything at all time, with a fair amount of hits per day.
For big sites, the cost of an appliance will be minimal compared to the big picture. So yeah...it can be done. But why? (note: Im sure there are some very very thin edge cases, if you're called Amazon, Google, or Ebay. But those are edge cases about everything)
[blockquote]I would have hard a time recommending to anyone to run their whole site in SSL. Get the logins or most forms in SSL, but the rest would be overkill.[/blockquote]
While most of your post is correct, not that part. Encrypting the login without encrypting the rest of the session is virtually completely pointless, since you leave your users vulnerable to session replay attacks. Yay, I don't know your password! Who cares, I have your authentication token.
There's no problem with researching creationism if you do it from an academic perspective.
Right now, even if creationism was true, we'd never be able to document it or prove it, because almost anyone who supports it does it blindly.
THATS the problem. Not creationism itself.
Hmmm, I can't tell if thats sarcasm...you CAN add -site:example.com to your search to block that site
Thats weird. I'm using chrome as my primary browser and for development (until i need firebug anyway. I dislike the Chrome dev tool), and my web app, with douzans of javascript files and hundreds of small images (nothing's combined or minified while I develop), when i hit refresh, loads up in less than a second.
Thats a "one page loads everything ahead of time and use javascript for everything" kind of app, so there's a LOT of files being loaded (far more than a standard web page, by a few orders of magnitudes), and its using windows authentication even for the images (during development only obviously), so caching is disabled across the board.
Even then, hitting refresh is almost instant.
[blockquote]7 runs barely on 512MB, adequately for small tasks on 2GB, ok on 4GB.[blockquote]
Ok, thats not 64mb of RAM, but...
http://phoenixmatrix.com/devblog/post/2009/07/05/A-story-of-Windows-7-and-memory-usage.aspx
It works perfectly well for "small" tasks like this too. My netbook that i use everyday, with Aero on, to do everything except gaming and software development is on 1 GB. You do NOT need 2 GB for small tasks.
The ironic part is that in all companies I worked for that went to upgrade away from XP, far and away the biggest hurdle was the browser =P
And yet, when they refuse to give primary support to stuff thats just a few years younger (the bullshit that is Windows XP), people go batshit insane on these very forums...
Microsoft has pretty strict support timelines for each of their products, provided up front, and, rightly so, stick to them.
So they'll stop supporting IE6 when all the products that requires it are out of their support time frame. (I think all of the relevent ones are in extended support now? So almost done)
Meh, you can still install 64 bit on top, and it just takes all your old data and dump it in a backup folder before wiping out everything else.
So sure, you have to reinstall your stuff, but you don't even "have" to make a backup of your stuff first, it will still all be there.
Copy your document directory at the right place and you're half the way there afterward.
My approach to every project is "use the right tool for the right job".
For public facing websites, the right tool will almost always be a CMS.
For the rest, it depends: for internal web app my personal favorite is usually a composite application framework. Unfortunately, unlike CMSs, there are very few of those, and the ones that do exist tend to be immature, so I had to write my own. Some internal web app projects are suitable for CMS too though.
If when you think CMS you think "biiiiiiiiiiiiiiiiiiig", you haven't looked at the good ones (ok, aside SiteCore: that thing is a behemoth, but it IS really awesome, as I mentionned before =P)
Totally agreed.
If, in this day and age, you're making a website from scratch, you're doing it WRONG. Exception only for specialized web applications that try to do "thick client" stuff on the web (let say something like gmail).
For normal public facing sites, or intranets, if you don't use a CMS, you'll have to replicate basic stuff for nothing. Sure, stuff like ASP.NET or PHP/Ruby/Python/Whatever frameworks will handle low level authentication, data access, navigation and whatsnot, but a CMS will give you a working web sites, with all that already in a working state, and you just need to add your styles, template, and business-specific logic and you're done.
Being a .NET dev, I use Umbraco (the best one is SiteCore by a landslide, and not just if you're a .NET dev...its just impossibly expensive. Worth it if you can afford it though). It handles all the stuff thats common to all websites, and not an inch more. Then doing anything "from scratch" that would take a few hours or days takes a few minutes, and you're not stuck with precanned impossible to modify garbage like some other major CMS will force on you: everything is easy to modify.
There's a million CMS out there in all flavors that offer all level of abstractions and specialization, depending on your requirement. Pick one, and stop wasting your time doing garbage from scratch.
Then explain how the guy in the article ran them in Windows 7 64 bit without any issue?
The very reason there IS a mysql_real_escape_string is one of the more well known occurance of what Im talking about. There was another case with Oracle about 2 years ago. Escape functions are unreliable.
And you can just dynamically create the SQL with concatenation, as long as the source of the data is trusted, and you use parameters, thus how you can do a prepared statements to do it: again, all good ORMs do it like this to deal with databases without a decent pivot function/facility.
You can still dynamically generate prepared statements. Thats how ORMs do it. Most RDBMs will even let you dynamically generate a prepared statement and call it within a stored procedure.
There's nothing mythical about it: escaping still sends a string to the database, and relies on the conversion algorithms of it to deal the values. Every so often, as more research is done in vulnerabilities of string encodings and whatsnots, people find ways to confuse the engines with some really screwed up strings. Its not magic: the attack surface area is just waaaaaaaaay bigger, since you're letting your application layer guess the behavior of the database, so any change to either side, and boom! Or do you think SQL injection is just about sneaking a second command to the first one by adding --, ;, or whatever terminator the database uses, like what most script kiddy attacks do?
Yup. It doesnt help that most samples you'll find online normally show the "easy quick way" of doing things, and often its the wrong way.
I'm an ASP.NET developer myself. ASP.NET has two "main" ways of working: WebForm (old), and MVC (new).
The MVC way has very good samples that generally show best practices. WebForm is technically superior in a lot of ways, but 99.999% of examples online show HORRILE HORRIBLE ways of using it.
Thus, virtually all WebForm code I've touched over a decade has sucked balls. Think worse than bad PHP code kindda sucked.
There's zero reasons for it to be that way: the "easiest" way of doing everything is actually the correct way. But all examples you'll find, all the blog posts, even huge commercial apps (SharePoint comes to mind, and its made by Microsoft itself!!) does it the wrong way according to the WebForm best practices.
PHP's just in the same boat as ASP.NET WebForms