Slashdot Mirror

Top 10

It seems to be due to the use of a click-jacking defense best-practice: https://www.owasp.org/index.ph...

Unfortunately this is inconvenient for NoScript users.

"AI and data science jobs are at the top of the list, in part because they're relatively young technologies"

Nothing particularly new in any of the fields mentioned. Specific frameworks in use are different now than they were 5, 10 or 20 years ago. However, speaking as someone who has been in IT for somewhere between 30 and 40 years, there's really not a lot that's fundamentally new. Mostly, we have added more turtles. What I do see is that each new generation re-invents old ideas and slaps new labels on them. Often, they even think the ideas are new, until some old grouch like me comes along and rains on their parade.

The last real sea change was the spread of the Internet in the 1990s - enabling worldwide networking (and worldwide attacks). The actual vulnerabilities being exploited, however, are old-hat. The top security risk today's web applications is injection? This has not changed in 20 years, which ought to be embarrassing for the entire IT profession.

You don't need elite, top of the line hacking abilities. Yes, if you want to break into high security areas where you're facing policies that Put the C of the CIA triad (read the link before you post conspiracy bullshit, please) before the A, then yes, Otherwise you're facing the same problem the average malware jockey faces: If you don't want a specific targets, there's plenty of easy ones.

Take a look at the OWASP Top 10. These are the 10 security issues that are considered the most critical and most common out in the field. Take a look at the 2017 edition, then 2014, then 2010. Notice something? They barely change. And believe it or not, the number 1, top level security issue has not changed since 2003.

If companies considered security at least a tertiary priority, do you think the most critical, most widespread and most common security issue would still be an issue? Or at least still be number 1?

[Avoiding] SQL-injection attacks is a really hard problem

NO! Avoiding SQL-injection vulnerabilities is a basic part of website coding and extremely easy to do, there is no excuse.

It's not a problem when a programmer pulls code out of his archive to put it to new use. What is a problem, though, is people googling their problem du jour that they cannot solve, find code that more or less does what they want, adapt it to their specs and consider that programming.

What you will usually find as one of the first hits that way is tutorial code that showcases the function that you might be after, but without any sanity checks and without the even barest minimal security in mind, simply because it is supposed to TEACH without distracting by adding code that doesn't contribute to the function.

That's why injection is still, after over ten years, the number one on the OWASP Top 10 list.

It has to be wrong to be ignorant; and it has to be at least almost-true to be insulting.

Someone on Slashdot started talking about IT degrees when I mentioned self-studying Computer Science. If you've ever looked at the two programs, you'd facepalm at warp speed: IT degrees include "general IT", network administration, and IT security; Computer Science is essentially a mathematics discipline based on exploring what can be computed (and how). They're not really equivalent in any sense.

You talk a lot about Docker and, I assume, have a lot of general Unix and perhaps Windows domain administration knowledge. That's good for an IT person. Other IT jobs include racking servers, running cables, and figuring out what size switch to buy. The thing is I learned Docker, too; I made use of it after reading TWO WEB PAGES, and spent several months tweaking and refining my approach. Many of the tools are immature, although that's mostly because clustering is hard--some really smart Computer Science people did a lot of work most of us don't understand, and we've worked out how to use Pacemaker and Corosync to "do the right thing" for us, even if configuration is beastly.

That's the point: it's all surface stuff. I picked up most of my IT administration skills by looking and thinking. Most IT people around me can both give me new information *and* learn from me, because the field changes a lot and I go pretty deep into the one or two things that matter to the tasks I'm trying to accomplish. I'm something of a Systems Engineer more than just an administrator, but not really qualified in the way a dedicated SE is.

All the stuff IT people do is learned by reading a book and working with an IT team for a few weeks or months, depending on how specialized.

IT isn't the domain of scientists, engineers, and frontier researchers; it's the domain of grunt work supporting scientists, engineers, and frontier researchers.

People come to me with requirements about running a software environment or supplying a level of service, and I use some off-the-shelf tools to hand them a solution in about ten minutes; then the programmers write an enormous accounting system using the databases and application servers I provided them on which to run said software. I am not a software engineer.

Network engineers use first principles to design networks, selecting routing protocols and VPN solutions like MPLS or IPSec; very-smart-sciencey-people design those routing protocols, design encryption algorithms, and even design the hardware. I don't understand the graph theory or the electrical engineering involved in making those things.

You want to know why we have so many security problems? IT Security people are operating on a checklist. They know what firewalls do, what encryption is for, and some things about access control. In the end, they're working from first principles: you need anti-virus and don't share passwords. IT Security is so bad because IT Security isn't a first-principle job; we *should* be hiring engineers. I have a Project Management certification, and part of that is an understanding of risk (something I understand *well* beyond PMI's domain); most IT Security people don't understand risk, so they don't project threat models and work out strategies to protect their organizations. They're actually supposed to.

Aside from IT Security being full of people who just plain don't know how to do their jobs, the IT field is essentially a field of mechanics and plumbers. Large IT departments are made primarily of people who can be EASILY REPLACED WITH HIGH SCHOOL GRADUATES, if they need to graduate high school at all. Even at places like Amazon, you have high-level engineers designing their services; programmers writing the software to connect together other software supplying that service; and a sea of cable monkeys whose job is to rack servers, run network cabling, and install softwar

Regarding cookies, you're always going to get one on my site, whether you are using Tor or not, to support logins. HTTP isn't session-based and you need cookies to simulate sessions, so that you can have logins and dispense privileges where appropriate.

If you hand out session IDs prior to authentication, you're vulnerable to session fixation. So giving session cookies to all visitors is not required for the purpose of supporting logins, since you're going to have to give them a new session ID after logging in.

HSTS support across browsers: https://www.owasp.org/index.ph...
Current usage stats: http://caniuse.com/#feat=stric...

IE: 11 (windows 7 and 8.1+)
Edge: all versions
Firefox: 4+
Opera: 12+
Safari: 7+ Mavericks (Mac OS X 10.9)
Chrome: 4.0.211.0

That will cover the majority of users.

Regardless, there is still no fallacy. Users can easily protect themselves from that situation by using a browser that supports HSTS, which simply means using a system that has been updated within the past several years. It also greatly reduces the attack footprint, which is the big selling point for this ad/article.

For sure. OWASP has a good guide on prevention. https://www.owasp.org/index.ph...

Except I don't think this is actually an SQL injection and so you could have the most secure database driver with prepared statements and all of that jazz and it probably wouldn't matter.

It looks like (the details I've read are pretty slim) it's actually a php object injection. Apparently, this has happened to Joomla before.

Basically it sounds like the useragent string is stored in the database correctly (but unverified and/or unsanitized) and then other code is pulling it from the database and trusting that it is a safe string when it's not. It's actually a string of a serialized php object. But they trust their database so they unserialize it and Bad Things(TM).
I could have that wrong, I haven't coded PHP in almost a decade.

Why not go one step further, do "the right thing" and use ADO Prepared Statements?

Oops, link to said section: https://www.owasp.org/index.ph...

An improvement to the above method:

$ convert rote66.png rote66_converted.png
$ mv rote66_converted.png rote66.png

If there exists a well-defined conversion such as an image file -> bitmap -> image file, running such a conversion will strip any possible exploit code inserted into the format.

Of course, this will not work if the file format by nature is exploitable, such as full-feature XML (see XXE).

"The modus operandi used by this criminal group is the so-called man-in-the-middle and involved repeated computer intrusions against medium"

Doesn't sound like my understanding of a man-in-the-middle attack more like emailing the victims malware and persuading them to execute it.

The Open Web Application Security Project website is a great place to start browsing from, to investigate both pen testing and secure development.

I would also recommend getting some familiarity with the PCI DSS standard. It is aimed at companies involved in online payments (and a bitch if you have to prove compliance.) However when used as a descriptive framework rather than a prescriptive one, it's great foundation for planning a company's IT security aspect.

I'm sure there's a bunch of other security standards for other industries that could be used in much the same way. A good security consultant should at least be able to name check them.

I'm a web developer and I also haven an interest in understand public-private key crypto, PGP, steganography, physical security etc. The thing is, You don't need *any* of that to build good, secure websites. You should be asking about things from the OWASP Top 10 List if you want to gauge their ability to write secure code.

https://www.owasp.org/index.ph...

Otherwise you're judging them for not having the same "other" unrelated-to-your-job security interests as you.

They should understand that they aren't trained enough to build their own authentication encryption systems correctly. They should use generally accepted procedures like BCrypting passwords with a unique per-user SALT that also uses a site-specific key. And that other sensitive fields should be blocked from being recorded in logs, data should be encrypted at rest, etc. But if they have poor OWASP skills, the sensitive data is still readable because it is accessed through the application which is decrypting it for an attacker.

You're asking the wrong things and judging on unrelated skills.

Hard-coded names are easy - you make some entries in your hosts file.

Applying the well-known APK workaround doesn't work when the application sees that the certificate doesn't match the certificate that the application expects.

Your connection to [Game Title] may be compromised!

Your Internet service provider (ISP) appears to be intercepting and changing traffic. [Game Title] cannot ensure that your connection to other players is secure.

Are you connecting through public Wi-Fi? Your provider may be sending a page asking you to log in to the hotspot using a web browser. To see if this is the problem, try logging in and playing again.

Are you playing on break time at work? Your office may be intercepting traffic to check it for viruses or data leaks. To see if this is the problem, try playing from another location.

Consider this scenario.

1. Evil hacker creates some malicious javascript that does three things: it attempts to connect to a local Asus router; upon finding one it reconfigures it to allow external access; after successfully hacking a router it opens a connection to his server to report another victim.
2. Evil hacker sets up a rogue WiFi hotspot in a coffee shop near your office, and lures people into connecting to his evil open proxy (check out the WiFi Pineapple if you want to see how such a device works, or if you just want to purchase one.)
3. The evil proxy injects the javascript into the bottom of whatever pages the victims visit, and modifies the cache-control directives to cache those pages for a long time. This is called a cache poisoning attack.
4. The evil hacker waits for one of those victims to return to your office with their poisoned laptop, reconnect to your network, open their browser, and re-visit one of the poisoned sites in their cache. The malware script launches in the user's browser, attacks your router from within the trusted side of your network, then visits his site to report "mission accomplished, here's the IP address of another hacked router." All of this is of course invisible to the average random coffee-drinking employee.
5. ???
6. I don't know exactly what happens in step 5, but it is likely nothing you would consider good.

This type of attack was fairly common when google was using http instead of https, and evil proxy operators could count on lots of people visiting the google page. It's still easy enough to do, and remains one of the biggest risks of trusting any unsecured wifi networks.

More often than not, the evil hackers are just phishing for random victims. But by setting up his access point in a coffee shop frequented by your employees, this is one way the evil hacker could target you specifically.

Parent is one side of the "why not". The other is, "why *would* we use ssh for everything?".

The summary (I'm not going to bother reading the article) makes it sound like they want to use ssh in place of HTTPS. That's stupid. We have secure protocols for many things that each fit correctly (ipsec, https, sftp, ssh, various-vpns (ssl/tls/etc), s/mime, pgp/gpg, etc).

The summary says, "SSH does have several cool features over HTTP/2 though, like built-in client authentication which removes the need for registration and remembering extra passwords."
WTF? I'm guessing they're referring to public key authentication, which HTTPS has (and I'd assume would work in HTTP/2 as well). You can use client based ssl certs for auth. It's a PITA, just as it would be to use ssh keys - the client side management of said info would need to be solved in a very dumbed down and friendly way.

Some other things it has (and I assume they imply that HTTPS does not have?):

* Binary protocol. ssh just sets up a secure channel. It's not a binary protocol for all the other bits (like shell commands), which are all encrypted plain text. Ditto to HTTPS/SSL/TLS... where's the difference here? HTTP/2 proposal would have a binary protocol, though I don't really see much benefit to that.

* mandatory encryption. ssh = nope. You can, but you could also allow the null cipher. IE. it has to be configured for that way of operations. HTTPS/SSL/TLS - enable HSTS header and do a permenant redirect on port 80 to 443, done.

* key pinning. Oh, you mean like this: https://www.owasp.org/index.ph...

* multiplexing. I'll admit this may be a benefit, but I see little benefit over simply using multiple connections with keepalive. Prove there's an actual performance benefit and then we'll talk. Meanwhile, as parent mentioned, ssh connection establishment is VERY SLOW in comparison to HTTPS.

* compression. You mean like this, "SSLCompression On". http://httpd.apache.org/docs/c...

Please note, I'm not saying HTTP/2 is bad, nor that the features in HTTP/2 fall to the same points above. I'm saying those points do not apply, apply poorly, or already have a better solution in HTTPS as compared to SSH.

These are embedded devices.

You install the patch or firmware update from your appliance vendor to address the insecure transport security vulnerability (Failure to utilize secure protocols such as SSH or HTTPS over Telnet/HTTP for administrative connections; transmission of usernames and passwords in cleartext withotu encryption).

Well companies can do much more to improve on that front though.
1. Architect the product, not just build it. All too often the focus is on meeting business objectives and security is added later. An product that was well thought-out and designed handles security as part of the core design as well as the business objectives.

This. Also, be sure to include threat modeling https://www.owasp.org/index.ph... as part of the architecture. Microsoft actually has a pretty good (free) stand-alone tool that you might want to check out: http://www.microsoft.com/en-us....

I guarantee you're not far, far smarter than us.

That really doesn't have to do much with "smart". Security for such things is mostly about checklists, knowing them and knowing which apply. A good start is CWE/SANS Top 25 Most Dangerous Software Errors and of course the OWASP Top 10.

Two tools that I use regularly to check Java artifacts: FindBugs: http://findbugs.sourceforge.ne... OWASP Dependency Check: https://www.owasp.org/index.ph...

See http://security.stackexchange.... and https://www.owasp.org/index.ph...

In short: a site can declare that it only uses one (or more) public keys on its secure sites and that this declaration is valid for a certain time period. Browsers that support pinning will check to see if those public keys (and no others) are being used during that validity period. If the key were to suddenly change, even if it's otherwise valid (e.g. issued by a trusted CA), the browser would complain that something is wrong.

This prevents rogue or compromised CAs from issuing certificates to sites that used pinned certificates (at least for the duration of the validity period).

For example, Google Chrome comes hard-coded with the public keys for Google sites. If an otherwise-valid certificate were created for Google sites (such as when the DigiNotar CA was compromised), Chrome would refuse to connect to any server using it because it does not match the built-in pinned value.

... by the developers. That a bug or vulnerability is found and announced in certain moment, be in closed or open source programs, don't ensure that the bad guys (working for the NSA or other places) haven't found and been exploiting it for some time already. That the bug can be found in automated ways (in this case was static source analysis, but could be checking for undocumented open ports or sql injection) makes almost certain that it could had been exploited before.

https://www.owasp.org/index.php/Main_Page

And between the things people must worry about are cameras, that are accessible from internet, with present or future vulnerabilities.

As pointed out by others, this 'problem' is nonsense because the random number is generated by the client's browser. A government could lean on browser providers, but that puts the 'attack code' client-side and waiting to be noticed.

Trust of keys from providers is a real problem. In order to be certain that a connection is actually secure from listening you have to trust that what you are getting is the real certificate from the service provider, and not an 'attack' certificate generated by some dodgy CA (e.g. DigiNotar and the Iranian google snooping, and others). This can be reduced in some (limited) cases by using certificate pinning, or by using something like EFF's SSL Observatory.
Even if you actually are getting the 'real' certificate, you need to trust that the service provider hasn't already handed that certificate over to government. This isn't just a problem for the current certificate trust model - obviously if the other person is giving away their keys then you're pretty screwed regardless of the encryption system.
Finally, even if the communication is encrypted and the spying group doesn't have the keys, you still have to trust the service provider to not just hand over the unencrypted network traffic or your content anyway.
That's a lot of trust being spread around.

In the case of something like gmail, the solution is more encryption - it is encryption of the content end-to-end rather than just in transit, and with keys only you and the recipient have. That could be personally exchanged self-signed x509 keys/certs or OpenPGP keys, or even preshared symmetric keys. If you're a bit more trusting, it could be keys signed by a trusted other (a genuinely trusted other, not a large company).

So the solution is more encryption - in part at least. Just not more TLS.

Can someone please come up with a "best practices" for this? Say "This is how you log a browser user in, this is how to check if a given browser is a logged in user, this is how to log out a user?" (That last one is important, no browser provides a logout button for Basic Authentication) Is storing everything server side in a session (referenced by a session cookie) the best way to do this? What about mobile users, is their IP static throughout a session or does their IP change if they change cells?

The Authentication Cheat Sheet is a good start, but basically cuts off at "use SSL, require long passwords, and make authentication someone else's problem with single-sign-on." Does anyone really know or have they merely amassed years of experience doing what they think is right?

I also linked to OWASP ZAP, which I used for most of the testing, partly because it is FOSS. Well, emphasis on the F, but the OSS is nice too.

ZAP should work fine for the kind of passive analysis I did for TFA, and if you're on a truly tight budget, you can certainly use it for more active testing. However, if you're going to do professional pen-testing, Burp is really worth shelling out for. It's the best web pen-testing tool I've seen, and I've heard the same thing from people I trust (including SANS instructors who are ZAP contributors). For professional work, it's a bargain at something like $500/year. Most professional security tools are 10+ times that expensive.

1. I don't understand why XSS and Injection are listed as separate items. XSS attacks are by definition injection attacks. I think separating this out de-emphasizes an important conceptual understanding applicable to a lot more domains than databases and html. To their credit they say as much.

They actually mean SQL Injection.

https://www.owasp.org/index.php/Top10

1) You seem to know nothing about Java and JVM security. It is immaterial what language you are using on the server-side, Java is no more or less secure than any other.

2) What difference does it make what the market share of a piece of software is. It is either SECURE or NOT SECURE. If it is not secure then it doesn't matter if one person uses it or 3 million, it is still not secure.

When evaluating the security of a web application there are many considerations (I've actually taught web app security courses and done all this stuff). You should certainly look at how many advisories there are on a given product. You should also see when these happened, how they were resolved, etc. It may be better to use an application that has had numerous issues that have been promptly fixed for instance. How easy are updates to roll out? How soon do fixes come out? Can you review the source code to look for good coding practices and engineering? As for SQL does the product EVER use anything but bind params? If it does construct dynamic SQL that's a red flag, but it MAY be OK if ALL input parameters are carefully cleaned (bonus points of something like perl's taint mode is in use). Ideally you'd also want to run a full security scan against your test install with a good fuzzer and see what happens. If you can easily shake out bugs yourself then that's a red flag too.

In other words you really can't sort out the security of an application by any simple formula, and certainly you need to use the right considerations. Anyone interested in getting more detailed advice would do well to start with something like OWASP https://www.owasp.org/index.php/Main_Page

OWASP has guidance; for instance, here: https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet#Insecure_Data_Storage_.28M1.29

From https://www.owasp.org/images/5/5e/Mobile_Security_-_Android_and_iOS_-_OWASP_NY_-_Final.pdf
2. Insecure data storage
Solution
  Avoid local storage inside the device for sensitive information
  If local storage is “required” encrypt data securely and then store Use the Crypto APIs provided by Apple and Google
  Avoid writing custom crypto code – prone to vulnerability

OWASP has guidance; for instance, here: https://www.owasp.org/index.php/IOS_Developer_Cheat_Sheet#Insecure_Data_Storage_.28M1.29

From https://www.owasp.org/images/5/5e/Mobile_Security_-_Android_and_iOS_-_OWASP_NY_-_Final.pdf
2. Insecure data storage
Solution
  Avoid local storage inside the device for sensitive information
  If local storage is “required” encrypt data securely and then store Use the Crypto APIs provided by Apple and Google
  Avoid writing custom crypto code – prone to vulnerability

Ummm.. fuck parent straight up the ass for that idiocy.

Validating your inputs is just one of many important parts of a complete security solution.

There is a good reason you'll find "Input Validation" given its own section starting on Page 5 of the OWASP Secure Coding Practices Quick Reference Guide.

But don't be too hard on CapOblivious2010 ... developers like that are the reason you'll still find plenty of work writing security code for decades to come.

I'd never heard about OWASP before but I found the Top Ten you refer to well worth taking in.

Direct link here for anyone interested: OWASP Top 10 Application Security Risks

you won't need to ask this question anymore.

Pretty bad advice. Unfortunately this is an area where you will continually need to keep asking the question. While there are certainly basics that should be covered there are also subtleties and interactions and new exploits in software you will depend on.

The OWASP top 10 is a pretty good starting point.

Be sure to checkout out all of the fine resources at http://www.owasp.org./ It's the Open Web Application Security Project. All materials, training, libraries, and content are free. There are numerous local chapters also so be sure to search for one in your local area.

I recommend taking a look at The Open Web Security Application Project. There are a significant number of resources listed on this topic.

Best,
Z

I've actually tried to follow through the site - installing the compiler, reading the manual and trying it out. First impressions:

1. The language itself is just a bastard sorry child of ocaml and erlang.
2. Both parents are specific languages with steep learning curve.
3. Using powerful paradigms with necessary horrible syntax makes no sense here - especially when webapp developers are your target audience.
4. Opa brings a lot of hidden "gay magic" (all-in-one binary, the whole client/server rpc thing, objectified xhtml), yet fails to deliver something meaningful.
5.To clarify the above, it doesn't make database models, templating, forms or MVC in general any easier - there is NO sweet spot hit as seen in ruby on rails or web2py - in fact, it's very, very lowlevel with neat erlang-like client/server model behind the scenes.

Database, or better said, the lack of thereof, is a topic in itself:

1. in OPA, there's a persistent storage of key/value, with a single index over it.
2. no SQL, not even noSQL, no nothing. if someone manages to actually query some fields past key/value storage, please enlighten me.
3. I suppose this is for the better, since well, we don't need to use real database queries in webapps, right? uh...

Note that these are first impressions, not necesarily correct. OPA is very interesting from academic standpoint - in fact its origins are in academia. Damn undergrads should know their place - ocaml, erlang even scheme never proven to be useful past np-hard problems. As far webdevs are concerned, we just want our import flying

Hello, I am Patrick. I cannot reproduce the email their staff replied with, except it says something along the lines of thank you for raising this matter for our attention and that is was fixed within an hour or two. Below is my email to them, with certain parts redacted, which includes the heavily debated script. The email was a follow up after a lengthy discussion with staff and they were most thankful for the call. I'm publishing this just so that you are better informed and can form your own opinions based on this. From: Patrick Webster [mailto:patrick@osisecurity.com.au] Sent: Thursday, 22 September 2011 1:26 PM To: [REDACTED] Subject: Privacy breach in pillar.com.au website Hello [REDACTED], Thanks for taking the time to speak with me today. As mentioned, I am a FSS member from my time a NSW Police Force. My personal background is in IT Security and I am the owner of OSI Security (www.osisecurity.com.au). You're welcome to see my personal history at http://www.linkedin.com/in/patrickwebster - the past 10 or 11 years I have been working in securing information systems etc, which is how I came across this bug. Yesterday, I received the FSS email notification to download my member statement. So I logged in to the pillar / FSS members portal and went to statements and clicked to download the statement, which is in PDF format. My *personal* statement is at https://services.pillar.com.au/FSSMembers/secure/Statement.aspx?documentId=107/1388-%5BREDACTED%5D8&page=0 You're welcome to have a look (I have [REDACTED] in super, yay). So after I saw my statement I noticed the 'documentId' number and, based on my security background, I have natural concerns my information is stored securely. So I incremented the number to see what happens (expecting to be rejected); I.e. https://services.pillar.com.au/FSSMembers/secure/Statement.aspx?documentId=107/1388-%5BREDACTED%5D8&page=0 becomes https://services.pillar.com.au/FSSMembers/secure/Statement.aspx?documentId=107/1388-%5BREDACTED%5D9&page=0 Amazingly (and coincidentally I might add) the statement I downloaded is my former colleague at [REDACTED] (if you look at my LinkedIn profile and see my connections you will see that we are connected). I then did a random spot test to see if it worked for any number, which indeed it did. I quickly wrote a linux bash script to enumerate documentId numbers and discovered it worked. Script source is below: #!/bin/bash #[REDACTED] for i in {[REDACTED]..[REDACTED]} do echo $i wget "https://services.pillar.com.au/FSSMembers/secure/Statement.aspx?documentId=107/1388-$i&page=0" --no-cookies --header "Cookie: [REDACTED]" done You can see the script runs from [REDACTED]..[REDACTED] in member numbers (just a guess on my part) and then tells the wget software to fetch the documentId with the 'for loop' number which is $i. I was then able to download every member statement, including my own of course. Naturally I find this extremely concerning so contacted you today (I found this around 9pm last night). All the data I obtained has been destroyed / deleted but validated my concerns. Ideally the pillar website should generate some kind of hash (such as member ID + unique salt = 'documentId') instead of a direct object reference. See: https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References That is about it... if you have any questions please contact me via email or details below. Kind Regards, Patrick Webster ...

IMHO SSL is often not the problem. Most websites/webapps are hacked through badly configured and unpatched servers or through programming errors in the site itself. If you're concerned about security, make sure that your website/webapplication/cms is secure. OWASP is a good source for hints and tips. They even have a top-10 for this stuff. So, if SHA-512 is you're only problem, you're doing just fine.

IMHO SSL is often not the problem. Most websites/webapps are hacked through badly configured and unpatched servers or through programming errors in the site itself. If you're concerned about security, make sure that your website/webapplication/cms is secure. OWASP is a good source for hints and tips. They even have a top-10 for this stuff. So, if SHA-512 is you're only problem, you're doing just fine.

FYI...Web Goat https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

This ^. +1. These are very basic mistakes we are seeing exploited. Its almost as if this is a company that is unaware of basic security practices (they could check out owasp for some hints). What seems more likely is a company that has been hacked, and begun playing the blame game rather than taking even the most rudimentary steps to secure their system. A press release is not an effective server hardening tool, its more of a provocation. So "Its only been a month" doesn't seem like any kind of excuse for a company as large and wealthy as Sony. A company with an apparently cavalier attitude towards sensitive user data.

I think what you're looking for is the Open Web Application Security Project (OWASP) Guide:

http://www.owasp.org/index.php/Category:OWASP_Guide_Project

It's pretty much the industry standard.

Don't teach how to remove viruses. That is a moving target. Teach how viruses spread though specific examples. I think cross site scripting (XSS) is easy to teach them once they've done a little html authoring and had a little javascript programming. For this socially networked generation it applies to stuff they use EVERY hour of every day. A few of there were probably hit by that mouseover twitter exploit a few weeks ago. You can run an intentionally vulnerable server such as mutillidae to practice the exploits. http://www.irongeek.com/i.php?page=security/mutillidae-deliberately-vulnerable-php-owasp-top-10 Read up on current exploits at http://owasp.org/ The future needs people to know how to not create exploits, and patch the ones they do. We don't need more IT "next clickers" who only know how to run third party solutions.

No. This is a Cross site Request Forgery attack. The Script in this case, was on the linked site, not in the tweet.

For those not in the know:

OWASP Cross Site Request Forgery Prevention sheet Sheet