Here, let me help you with a little psudocode: String sUserId = request.getParameter("user_id"); int userId = 0; try {
userId = checkInt(userId);
if (userId < 0) throw exception; } catch (Exception e) {
exit(); } User user = (User)session.getParameter("current_user"); if (user.getId() != userId) {
exit(); }
Really intelligent post. I have no problem with AVG scanning a file as it hits the hard drive - scanning files of web pages as you surf (that's already happening) - it's the predictive scanning that was a poor architectural decision from AVG. I'm glad to see they are backing out of that decision.
I look forward to the day where adblock, flashblock and noscript are standard features in a browser.
The problem is no so much the consumer experience... (although consumers experience was changed significantly as web searching became a lot more resource intensive).
The problem is that the link scanning featured caused a great deal of traffic to sites - even sites that consumers did not visit. That's not cool.
I use AOL every day. All the CD's they sent me in the past make great coasters for my drinks!
But I'm not crazy enough to actually use their dial-up service. Crazy.
What really shocked me was the Netflix told their subscribers that they were removing the profiles feature - but tried to pass it up as a service improvement. FUD! But I do give them credit for hte reversal. I'm very fond of this feature.
Right, and then you are logged into your GMAIL account all day leaving you vulnerable to CSRF and Session Hijacking type attacks that are quite common in GMAIL. You are better off using GMAIL pop/imap capabilities or only log onto GMAIL for the length of time needed to check your email.
You want to do your best to reduce the active session as much as possible.
If you constantly find flaws by hiring pentest firms, you are in the wrong stage. You need to get Secure SDLC built into your development and actually try to catch these flaws in the design phase.
That is great in theory, and might be true in the future, but you are missing the reality of the software development industry as it stands today.
1) Universities are not teaching software engineers about application security.
2) Most development organizations do not have leadership that understand the complexities and processes needed for secure software engineering.
3) Network Security training organizations like SANS teach courses around application security that barely teaches developers the skills needed to write secure applications. They still approach appSec from an operations point of view - where just like WAF deployment, you are too late or doing to little.
To really crack the AppSec nut, I recommend you approach this problem from several angles.
1) Start by (continuously) training your developers regarding application security. There are few firms that really do this well in a developer-centric way. Aspect Security ( http://www.aspectsecurity.com/ ) and Whitehat Security ( http://www.whitehatsec.com/ ) are 2 of the leaders in this field.
2) Begin building in-house application security pentest teams - this is a very different skill set than netSec pen testers. (You are right, you cannot just keep hiring pentest firms for the long haul)
3) Next do a risk assessment and catalog your applications current risk posture. Management appSec training is needed during this phase, as well.
4) Bring in a appSec pentest firm to assess your highest risk applications. Keep track of these results carefully so that fixes from developers can be tracked over time to verify that you are really reducing the applications risk posture over time.
Achieving application security excellence is a difficult process. And 3rd party application security training and application security pentesting (assessment) is critical on the path to success.
Functionality tests are easy to prove through unit and integration testing. Normal users spot functionality bugs quickly during normal product cycles.
However, security bugs are not easy to test or discover. In fact, it's very expensive to do testing to uncover even some easy classes of security vulnerabilities. Normal users do not stumble on security problems like they do with functionality issues.
Also, none of your developers were ever taught anything about application security in college. They professors are clueless. Even Michael Howard from MS who is hiring out of the best universities in the world cannot find a new grad who has any clue how to build secure software.
Functionality bugs and Security bugs are apples and oranges and deserve very different consideration. (Like measurement of Risk, etc)
Last, you can make a piece of software work. But you an never make a piece of software secure, only reduce risk to an acceptable level.
The just began opened up a 100 million dollar manufacturing facility. It takes time to ramp up production. They are targeting municipal solar - not consumer.
I'm glad to see you quote Nanosolar. That is the company to watch. A few years back most solar R&D went into 2 camps - one camp tried to advance the underlying solar technology and mostly failed.
Another camp went the route of just trying to fine-tune manufacturing (to reduce cost for mass production). That's where Nanosolar comes in. The technology behind Nanosolar in terms of energy creation is old news - but the fine tuning in the manufacturing process (super cheap "plain air" facilities) is what is so stellar about the company. Their thin-film solar panel stock is currently sold out until 2009 since several large municipal solar power generation plants bought their stock already.
Good software means lacking in bugs, maintainable, modifiable, scalable, etc... Do not forget security. In the web world, you need to abide by the OWASP TOP 10 defense principals http://www.owasp.org/ - it's a very difficult aspect of Code Quality - very few developers have even a clue about what application security is. No university trains developers to write secure code, hence most websites are insecure (XSS, CSRF, Access Control Issues, etc).
> Plus that iPhone development = Cocoa development = Mac development.
The iPhone is NOT OS X, no matter that crack Steve Jobs is trying to cram into your brain.
Actually I find SourceForge to be cumbersome for development. Google code is much easier to use.
PS: The idea of getting "highly skilled software engineers to work on your project for free" is over. Find a corporate/university sponsor and pay someone - or find a corporate/university sponsor who is willing to donate an engineers time to the project. Or be VERY patient and be happy for a small amount of progress. Many paid engineers work on projects like Linux.
You're old when your youngest needs a sitter for you. Youngster.
You're old when you live in a home full of sitters that provide you with daily scheduled activities.
Except for that sniper who sits in the upper right hand corner of the international terminal. He let me see his gun once and explained to me what a top notch shot he was. DANG that boy is NOT joking around!
I agree, Postgres is SOLID. Not a bad choice. For those who have already invested heavily in MySQL, I do not think you need to jump off the cliff, yet.
Make your life easier, just fork the backup stuff. The vast majority of MySQL is staying open source - Sun needs the free coders. It's just the backup stuff that Sun wants to privatize.
Honest to God, I once heard some ponce in San Francisco ordering a capuccino with half low-fat and half skim-milk foam. For the price that companies charge for crappy (roasted months ago) coffee, I not only should be able to get half (anything) in it, but I better start getting a free BJ on the side, too. Freaking aye, 6$ for a latte?
Slashdot Mirror
Here, let me help you with a little psudocode:
String sUserId = request.getParameter("user_id");
int userId = 0;
try {
userId = checkInt(userId);
if (userId < 0) throw exception;
} catch (Exception e) {
exit();
}
User user = (User)session.getParameter("current_user");
if (user.getId() != userId) {
exit();
}
Really intelligent post. I have no problem with AVG scanning a file as it hits the hard drive - scanning files of web pages as you surf (that's already happening) - it's the predictive scanning that was a poor architectural decision from AVG. I'm glad to see they are backing out of that decision.
I look forward to the day where adblock, flashblock and noscript are standard features in a browser.
The problem is no so much the consumer experience... (although consumers experience was changed significantly as web searching became a lot more resource intensive).
The problem is that the link scanning featured caused a great deal of traffic to sites - even sites that consumers did not visit. That's not cool.
I use AOL every day. All the CD's they sent me in the past make great coasters for my drinks!
But I'm not crazy enough to actually use their dial-up service. Crazy.
What really shocked me was the Netflix told their subscribers that they were removing the profiles feature - but tried to pass it up as a service improvement. FUD! But I do give them credit for hte reversal. I'm very fond of this feature.
Right, and then you are logged into your GMAIL account all day leaving you vulnerable to CSRF and Session Hijacking type attacks that are quite common in GMAIL. You are better off using GMAIL pop/imap capabilities or only log onto GMAIL for the length of time needed to check your email. You want to do your best to reduce the active session as much as possible.
If you constantly find flaws by hiring pentest firms, you are in the wrong stage. You need to get Secure SDLC built into your development and actually try to catch these flaws in the design phase.
That is great in theory, and might be true in the future, but you are missing the reality of the software development industry as it stands today.
1) Universities are not teaching software engineers about application security.
2) Most development organizations do not have leadership that understand the complexities and processes needed for secure software engineering.
3) Network Security training organizations like SANS teach courses around application security that barely teaches developers the skills needed to write secure applications. They still approach appSec from an operations point of view - where just like WAF deployment, you are too late or doing to little.
To really crack the AppSec nut, I recommend you approach this problem from several angles.
1) Start by (continuously) training your developers regarding application security. There are few firms that really do this well in a developer-centric way. Aspect Security ( http://www.aspectsecurity.com/ ) and Whitehat Security ( http://www.whitehatsec.com/ ) are 2 of the leaders in this field.
2) Begin building in-house application security pentest teams - this is a very different skill set than netSec pen testers. (You are right, you cannot just keep hiring pentest firms for the long haul)
3) Next do a risk assessment and catalog your applications current risk posture. Management appSec training is needed during this phase, as well.
4) Bring in a appSec pentest firm to assess your highest risk applications. Keep track of these results carefully so that fixes from developers can be tracked over time to verify that you are really reducing the applications risk posture over time.
Achieving application security excellence is a difficult process. And 3rd party application security training and application security pentesting (assessment) is critical on the path to success.
Functionality tests are easy to prove through unit and integration testing. Normal users spot functionality bugs quickly during normal product cycles.
However, security bugs are not easy to test or discover. In fact, it's very expensive to do testing to uncover even some easy classes of security vulnerabilities. Normal users do not stumble on security problems like they do with functionality issues.
Also, none of your developers were ever taught anything about application security in college. They professors are clueless. Even Michael Howard from MS who is hiring out of the best universities in the world cannot find a new grad who has any clue how to build secure software.
Functionality bugs and Security bugs are apples and oranges and deserve very different consideration. (Like measurement of Risk, etc)
Last, you can make a piece of software work. But you an never make a piece of software secure, only reduce risk to an acceptable level.
The just began opened up a 100 million dollar manufacturing facility. It takes time to ramp up production. They are targeting municipal solar - not consumer.
I'm glad to see you quote Nanosolar. That is the company to watch. A few years back most solar R&D went into 2 camps - one camp tried to advance the underlying solar technology and mostly failed. Another camp went the route of just trying to fine-tune manufacturing (to reduce cost for mass production). That's where Nanosolar comes in. The technology behind Nanosolar in terms of energy creation is old news - but the fine tuning in the manufacturing process (super cheap "plain air" facilities) is what is so stellar about the company. Their thin-film solar panel stock is currently sold out until 2009 since several large municipal solar power generation plants bought their stock already.
No, you mean (meep, meep) this! http://www.youtube.com/watch?v=3AdFA6WWJ7E
I'll build web 2.0 applications with JDK 1.0.2, notepad and MS Access 1.0 so long as they pay my 150/hr USD rate and have low expectations!
> Plus that iPhone development = Cocoa development = Mac development. The iPhone is NOT OS X, no matter that crack Steve Jobs is trying to cram into your brain.
Java Mobile = open platform used by cell phones from almost every vendor iPhone mobile = proprietary platform for 1 phone on the market
Meep meep, meep!
use java
WinZip with AES 256 encryption using a very strong password delivered via phone is sufficient in some situations.
PS: The idea of getting "highly skilled software engineers to work on your project for free" is over. Find a corporate/university sponsor and pay someone - or find a corporate/university sponsor who is willing to donate an engineers time to the project. Or be VERY patient and be happy for a small amount of progress. Many paid engineers work on projects like Linux.
Except for that sniper who sits in the upper right hand corner of the international terminal. He let me see his gun once and explained to me what a top notch shot he was. DANG that boy is NOT joking around!
I have scissors to snip up your paper!
I agree, Postgres is SOLID. Not a bad choice. For those who have already invested heavily in MySQL, I do not think you need to jump off the cliff, yet.
Make your life easier, just fork the backup stuff. The vast majority of MySQL is staying open source - Sun needs the free coders. It's just the backup stuff that Sun wants to privatize.