Hello guys,
Kind of thought I'd need a part-time job to while away some time as I'd be having only two modules this semester... and I found this quite reasonable...
http://www.earnparttimejobs.com/index.php?id=3128851
You can check it out. Its quite cool. Very flexible plus you can work from any part of the world.
Good Luck!!
A. Y. Au-Nlaro
Monday, January 10, 2011
Thursday, November 25, 2010
HTML5 and Flash
HTML5 and Flash
There has been recently this huge contention in the world of web technologies as to whether Flash’s supremacy is at stake with the arrival of HTML5. I think Flash has no choice but to frown at it’s sooner or later rival and more welcomed successor HTML5, because certainly HTML5 would sideline Flash. If not for anything, it will at least for the “royalty” issue. We all are advocates of “the Open Web” and the Open Standards (Open Source Initiatives) that support it, at least for a fair play on the web.
The fact is that, having the web flooded with proprietary standards, it is possible to get locked into one vendor’s or patent owner’s noose, necessitating royalties and thereby making services on the web sell much more expensive and owned, which jeopardizes the effort towards the free web/internet. Imagine what it would be like if some company owned the HTTP protocol and requires that royalties be paid for each and every use of the protocol.
I think the situation for Flash is like, Flash has contributed its quota for the development and sustenance of the web at a time all other (open) rivaling technologies failed to deliver up to what is required or obtainable with Flash. Now that should mean time has come for Flash to start thinking of something else to hold unto than being the bedrock for web multimedia. Because the presence of all these arguments indicates it wouldn’t be long when a promising open technology such as HTML5 replaces Flash. Even though the present situation might not be this harsh for Flash, from all indications however, this cannot be that far.
Flash is rich for what its best known for, and also, very much well integrated into almost all web developers tools, and the love for it, its familiarity among the developers community is not negligible. Nevertheless, all these does not mean that Flash is indispensable. Take for example, if Apple is able to decide off on Flash without being severely hurt, then its very much possible to come across an open technology such as HTML5 that displaces Flash as well. It’s a matter of time and enrichment. HTML5 is just a “still in the process” technology and is able to raise this amount of fear for Flash, means its not just hype.
Although Apple’s Flash feud with Adobe might be highly strategically focused on business and other rivalry contentions, which I may not want to dabble into, I think Steve Jobs’ “Thoughts on Flash” – (http://www.apple.com/hotnews/thoughts-on-flash/) to an extent, are quite reasonable. It is true that Flash has security issues of which even Adobe is fully aware, it is also true that Flash is an aging technology that fails to address a large set of consumer base which these companies, these professionals – the developers etc desperately wants to reach – the mobile users. Flash was designed for PCs using mice, not for touch screens using fingers. Since many Flash websites largely rely on “rollovers”, which pop up menus or other elements when the mouse arrow hovers over a specific spot. Most of the revolutionary multi-touch interface of mobile devices does not use a mouse, and there is no concept of a rollover. Which means most Flash websites will need to be rewritten to support touch-based devices in order to reach that vast pool of consumer base. If developers need to rewrite their Flash websites, why not use modern and open technologies like HTML5, CSS and JavaScript?
HTML5 remains a threat to Flash because that’s what it’s designed for. HTML5 is purposefully, like many other Open Source projects such SMIL, AVG, UIRA and Ajax Animator etc, designed to get the proprietary flash out of the way of “Open Web”. HTML5’s many capabilities such as the support for multimedia content (
possible with elements such as the audio, canvas, video etc) and drag-and-drop style operations, and many, many more, indicates high chances that it would be the appropriate and long awaited open standards successor to Flash. The underlying principle is simple: Web sites are designed to reach out to and provide readily accessible services to current and prospective customers. These customers decide the rules of the market. No company loosing customers will sit back and hold tight to any technology holding it to ransom. If this pool of consumers on the mobile and touch-based platforms, with many on others such the Apple’s that denies support for flash, are either able to be satisfied by other technologies such as HTML5, by other developers and/or other businesses etc, which means certainly some businesses, developers and/or technologies such as Flash might already be loosing out, or instead, that these companies, these businesses and/or these developers would have to redesign and/or rewrite their websites to provides services using technologies that is able to reach to their mobile and touch-based customers, then certainly the demise of Flash as the carrier technology for web multimedia has just arrived.
HTML5 is just a draft. By the time the video codec stuff is finally agreed and other necessary fixes are put in place, no one needs to argue whether HTML5 means anything to Flash.
Below are some set of interesting information about this topic:
HTML5 is the next major revision of the HTML standard, currently under development. Like its immediate predecessors, HTML 4.01 and XHTML 1.1, HTML5 is a standard for structuring and presenting content on the World Wide Web. The new standard incorporates features like video playback and drag-and-drop that have been previously dependent on third-party browser plug-ins such as Adobe Flash and Microsoft Silverlight. (Wiki)
Flash manipulates vector and raster graphics to provide animation of text, drawings, and still images. It supports bidirectional streaming of audio and video, and it can capture user input via mouse, keyboard, microphone, and camera. Flash contains an Object-oriented language called ActionScript.
Flash content may be displayed on various computer systems and devices, using Adobe Flash Player, which is available free of charge for common web browsers, some mobile phones and a few other electronic devices (using Flash Lite). (Wiki)
Until the advent of HTML5, displaying video on a web page required browser plugins, which are uniquely implemented by third party vendors. Virtually all browser plugins for video are free and cross-platform, including Adobe's offering of Flash Video, which was first introduced with Flash version 6. Flash Video has been a popular choice for websites due to the large installed user base and programmability of Flash. In 2010, Apple publicly criticized Adobe Flash, including its implementation of video playback for not taking advantage of hardware acceleration, one reason Flash is not to be found on Apple's mobile devices. Soon after Apple's criticism, Adobe demoed and released a beta version of Flash 10.1, which takes advantage of hardware acceleration even on a Mac. (Wiki)
HTML 5 is gaining ground as a competitor to Flash: the canvas element enables animation, and scripting can be synchronized with audio and video element timeupdate events. In one example of this, Scribd, a 50 million user a month document sharing website, announced in May 2010 that after three years of investment in Flash, it is changing from that platform to the HTML5 standard. (Wiki)
WebM is a multimedia container format designed to provide a royalty-free, high-quality open video compression format for use with HTML5 video. The project's development is sponsored by Google. A WebM file consists of VP8 video and Vorbis audio streams, in a container based on a profile of Matroska. (Wiki)YouTube now offers WebM videos as part of its HTML5 player experiment.[40] All uploaded files with resolutions from 720p and above are encoded to WebM in 480p and 720p, and other resolutions will follow.[41][42] YouTube has committed to encode their entire portfolio of videos to WebM. (Wiki)
As of April 2010, in the wake of Apple iPad launch, a number of high-profile sites have started to serve H.264 HTML5 video instead of Flash for user-agents identifying as iPad.[49]As of May 2010, HTML5 video is not currently as widespread as Flash videos, though recent rollouts of experimental HTML5-based video players from DailyMotion[50] (using Ogg Theora and Vorbis format), YouTube[51] (using the H.264 and WebM formats) and Vimeo[52] (using the H.264 format) suggest that interest in adopting HTML5 video is increasing.
According to a YouTube blog post, the <video> tag does not currently meet all the needs of a website like YouTube[53]. The main reasons stated include the lack of a standard format, the absence of an effective and reliable means of delivering the video to the browser, JavaScript unable to display video fullscreen, and content protection issues. Hulu also has not adopted HTML5 video due to the inability of providing the user with adaptive bandwidth videos, securing the producer's content, and providing advertisers with data. (All thanks to Wiki :)
Wednesday, November 24, 2010
WEB 3.0
Web 3.0
There are many views of what web 3.0 is, what it would be like and what would make it possible. Without disputing any of the many views, I would like to add that, what I see for the fast approaching future of the web, web 3.0, is what I would like to call “the Active Web”.
Definition
By “the Active Web”, I intend to describe how the web would become more or less personified, possessing inherent capabilities to actively interact with people and for people, when all the technologies required for realizing web 3.0 are fully explored and the multi-vision web 3.0 completely materializes.
An example of such maturity can be observed from the current state of web 2.0 now; at its peak of functionality and relevance with the evidences of; web communities, user generated contents, web syndication, “state-full web transactions on the stateless web protocols” etc.
When it finally arrives, the web would be able to perform intelligent and useful actions with little or no supervision, and it will be able to learn new trends, accumulate knowledge and exhibit even greater and more useful smartness. At this stage, the web would be richly endowed with smart protocols and applications capable of analyzing and completing intelligent user tasks with the help of enabling technologies such as embedded sensors on the hardware side, and ontologies on the software side, for example.
Such knowledge gathering for effective representation and efficient role-playing would be possible seeing that the web is one such rich data warehouse housing nearly everything one could ever think of… “in one way or the other”… think of the readily available user preference statements or some sort of profiles, user web-behaviors or browsing patterns, user generated and professional contents etc the fact is the web is content rich such that useful content analysis for intelligent behaviors is possible come web 3.0.
The general characteristic of web 3.0 is that it will make life for web patrons a lot much easier and entertaining while being very robust and intelligent in solving user needs. This will be possible by shifting attention and expertise (systems design and development) much closer to human language and behaviors, in other words, human intelligence; immediately understanding and inferring user intent and making suitable and friendly suggestions, eliminating unnecessary and boring “usually-required” user interactions, thereby completing tasks much faster, more intelligently and granting the user more satisfaction and relaxation.
For example, a search could accept any level of complexity in the “search description” and return only the most relevant hit(s) only, eliminating less useful and out-of-context hits. Or, enabled mail clients and email services that are able to filter and analyze the usefulness of messages from all incoming messages and act accordingly. A user could even be alerted in some cases, depending on the real situation with a mail, since user’s often also can connect with their mobile phones. These and many more smartness and proactivity would be witnessed in the era of web 3.0.
The vision is, since web 2.0 is able to allow users personal presence on the web through web communities, blog sites etc, given some significant improvements and inventions, evolution to a new web experience is generally feasible. That is, we may come to a state where the web becomes very familiar with its users and possibly learn certain of their behaviors to be able to make certain suggestions to them and/or decisions for them. The former is common place on the present web. The later might not be that evident, but with the full materialization of web 3.0, the activeness of the web would be quite visible.
The necessary technological enablers required for this experience are numerous and non-exhaustive as still many are yet to be determined.
The most basic of these enablers include: -
Ø Content definition and representation technologies such as XML: with appropriate content definition and representation such as metadata, web 3.0 agents are able to uniquely identify and analyze web contents for better reactions such as discriminate retrieval etc.
Ø Ontology Definitions: defining meaning and relationships between data and data elements about the many subjects on the web. Web Ontology Language (OWL): allows relationships to be inferred between data that is stored in different parts of the same application.
Ø More agile protocols, intelligent or smart devices etc
Session Hijacking
Session hijacking
Definition
Session hijacking is the act of taking over an authorized, already established transaction (communication scenario) illegally, through various ways of obtaining a session identifier used for the rest of the transaction (communication scenario) between a web server and a client.
Introduction
Session hijacking is a serious issue in web applications. That is, it constitutes concerns that call for the attention of both web developers and users. With session hijacking, a lot is at risk, e.g. user data – including access credentials, credit card details, user profiles etc; corporate data, and the integrity of web applications and their developers, which may sometimes involve certain legal rights like law suits etc.
To adequately define what session hijacking is, and what it entails – the threats it posses and the necessary measures to help mitigate risks, there is the need to understand what a session is, and the “very-important” session identifier too. In telecommunication, a session is a series of interactions between two communication end points that occur during the span of a single connection. Typically, one end point requests a connection with another specified end point and if that end point replies agreeing to the connection, the end points take turns exchanging commands and data ("talking to each other"). The session begins when the connection is established at both ends and terminates when the connection is ended. With web applications, this is not as easy as such: reasons because HTTP, the communication bed-rock for web applications is stateless. A stateless protocol does not require the server to retain information or status about each user for the duration of multiple requests. For example, when a web server is required to customize the content of a web page for a user, the web application may have to track the user's progress from page to page. Hence, it does not guarantee a session that lasts longer than a “request-and-response”. Now you guessed it, not many meaningful and useful transactions can be completed with just a “single” request-and-response operation in real life. Or if not, let’s consider an example: supposing you want to carry out an online transaction that requires user authentication, say, check mails, which requires you to log in with your username and password, or in other words, access credentials. Now supposing you asked the server for the mails and they asked you to tell who you are, that is requesting your access credentials, then you went ahead to provide the credentials, but on receive those credentials, the server/application no longer remembers what you wanted!! Or for better granularity, say after providing your access credentials and you are now provided with your web mail page, you then went ahead to access inbox, then the server asks again, who are you? Which means, it has already forgotten your credentials, which further means that, with every operation that requires access to secured data/information, you would always be asked to provide your access credentials… that would be pretty stupid right? But that’s what HTTP can provide, since it is stateless.
Now, web applications need to get around these short-live transactions (request-and-response long transactions) provided by HTTP, to make sense to web users and even from the application’s view point and/or domain. Hence, with respect to web applications, a session, or a web session, is a collection of related HTTP sessions (requests-and-responses) or different TCP network connections, that completes a meaningful and useful transaction from the user’s and/or applications view point. Sometimes a web session is also constrained by certain duration of inactivity, depending on the level security requirements and definitions of an application. For example, with e-banking, a session may be restricted to say only every one complete “transaction”, any further transaction(s), may be defined as a separate session to thwart hackers for example. And in other cases or applications such as the web mail, it may be duration constrained, say the system/application automatically ends your session (logs you out) after some time of idleness etc. Session management is the technique used by web developers to make the stateless HTTP protocol support this, otherwise known as “session state”. For example, once a user has authenticated herself to the web server, her next HTTP request (GET or POST) should not cause the web server to ask her for her account and password again. The session information is stored on the web server using the session identifier (session ID) generated as a result of the first (sometimes the first authenticated) request from the end user running a web browser. The "storage" of session IDs and the associated session data (user name, account number, etc.) on the web server is accomplished using a variety of techniques including, but not limited to: local memory, flat files, and databases. A common solution is the use of HTTP cookies. Other methods include server side sessions, hidden variables (when the current page is a form), and URL-rewriting using URI-encoded parameters, e.g., /index.php?session_id=some_unique_session_code. This session “unique” identifier is all that is needed for the remainder of a whole session, after the necessary authentication and verification processes, and can be communicated between the machines and not interrupting or otherwise annoying the web user with random authentication requests for each operation. This is when the attacker wants to strike, to obtain this session ID and continue with the session, by somehow stopping the legitimate user from participating (e.g. Denial of Service), hence, this session is said to be hijacked.
Session Hijacking
When you log onto a website that requires a username and password, that is when you tell Facebook, Yahoo, Amazon, or whoever it is who you are. At this point the website gives you a cookie. For the rest of the session the website is constantly looking at the cookie to determine who you are. If someone else has the cookie the website will not know it, but they will trust that it is you and provide the same access that you already have.
Session hijacking can be done at two levels: Network Level and Application Level. Network layer hijacking involves TCP and UDP sessions, whereas Application level session hijack occurs with HTTP sessions. Successful attack on network level sessions will provide the attacker some critical information which will then be used to attack application level sessions, so most of the time they occur together depending on the system that is attacked. Network level attacks are most attractive to an attacker because they do not have to be customized on web application basis; they simply attack the data flow of the protocol, which is common for all web applications.
TCP hijacks are meant to intercept an already established TCP sessions between any two communicating parties and then pretending to be one of them, finally redirecting the TCP traffic to the hacker by injecting spoofed IP packets so that the hacker’s commands are processed on behalf of the authenticated host of the session, as authentication is only required at the time of establishing connection. What is left now is how to alter the sequence and the acknowledgement numbers of the spoofed packets which the server is expecting from the client. Once it is altered, hijacker injects its own forged packet in the established session before the client can respond, ultimately desynchronizing the original session, because the server will now expect a different sequence number, so the original packet will be trashed, based on the anticipation of sequence numbers. TCP session hijacks can be implemented in two different ways: steal the packets then try to modify it to take over the session e.g. Man in the Middle Attack, Source-Routed IP (packet sniffing) or try to guess a valid packet e.g. the Blind attack (aka Brute Force Attack).
Packet sniffer comes in two categories: Active and Passive sniffers. Passive sniffers monitors and sniffs packet from a network having same collision domain i.e. network with a hub, as all packets are broadcasted on each port of hub. Active sniffers works with Switched LAN network by ARP spoofing. Once the hijacker reads the TCP header, he can know the sequence number expected by the server, the acknowledgement number, the ports and the protocol numbers; so that hijacker can forge the packet and send it to the server before the client does so. Another way of doing so is to change the default gateway of the client’s machine so that it will route its packets via the hijacker’s machine. This can be done by ARP spoofing (i.e. by sending malicious ARP packets mapping its MAC address to the default gateways address so as to update the ARP cache on the client to redirect the traffic through the hijacker).
If the attacker is not able to sniff packets, the attacker has to implement “Blind Session Hijacking”, which requires the attacker to brute force the packets.
Since UDP does not use packet sequencing and synchronizing; it is easier to hijack than a TCP session. The hijacker has simply to forge a server reply to a client UDP request before the server can respond. If sniffing is used then it will be easier to control the traffic generating from the side of the server and thus restricting server’s reply to the client in the first place.
These same techniques could be successfully applied to the HTTP sessions at the application layer to obtain the session ID.
In general, there are three primary techniques for hijacking sessions:- Brute Force or Blind attack - the attacker tries multiple IDs until successful.
- Calculate - in many cases, especially HTTP session IDs at the application layer, are generated in a non-random manner and can be calculated.
- Steal - using different types of techniques (packet sniffing), the attacker can acquire the Session ID.
- Session fixation, where the attacker sets a user's session id to one known to him, for example by sending the user an email with a link that contains a particular session id. The attacker now only has to wait until the user logs in.
- Session sidejacking, where the attacker uses packet sniffing to read network traffic between two parties to steal the session cookie. Many web sites use SSL encryption for login pages to prevent attackers from seeing the password, but do not use encryption for the rest of the site once authenticated. This allows attackers that can read the network traffic to intercept all the data that is submitted to the server or web pages viewed by the client. Since this data includes the session cookie, it allows him to impersonate the victim, even if the password itself is not compromised. Unsecured Wi-Fi hotspots are particularly vulnerable, as anyone sharing the network will generally be able to read most of the web traffic between other nodes and the access point.
- Alternatively, an attacker with physical access can simply attempt to steal the session key by, for example, obtaining the file or memory contents of the appropriate part of either the user's computer or the server.
- Cross-site scripting, where the attacker tricks the user's computer into running code which is treated as trustworthy because it appears to belong to the server, allowing the attacker to obtain a copy of the cookie or perform other operations.
Countermeasures
Defending a network against session hijacking requires implementing security measures at both the Application level and Network level. Network level hijacks can be prevented by ciphering the packets so that the hijacker cannot decipher the packet headers, to obtain any information which will aid in spoofing. This encryption can be provided by using protocols such as IPSEC, SSL, SSH etc. Internet protocol security (IPSEC) has the ability to encrypt packets on some shared key between the two parties involved in a communication. IPsec runs in two modes: Transport and Tunnel. In Transport Mode only the data sent in the packet is encrypted while in Tunnel Mode both packet headers and data are encrypted, so it is more restrictive. To Prevent Application sessions from being hijacked, it is recommended to use Strong Session ID’s so that they cannot be easily brute forced or use encryption as well. SSL (Secure Socket layer) and SSH (Secure Shell) also provides strong encryption using SSL certificates so that session cannot be hijacked, but tools such as Cain & Bell can spoof the SSL certificates and decipher everything! Expiring sessions after a definite period of time requires re-authentication which will futile the hacker’s tricks.
In general, most common methods to prevent session hijacking include:
- SecureSessionModule used by Applications developed on the ASP.NET platform. SecureSessionModule modifies cookies by appending a hashed message authentication code (MAC) to the session ID. The MAC is generated from the session ID, the network address portion of the requestor's IP address (for example, the 192.16 in 192.16.0.14), the User-Agent header received in the request, and a secret key stored on the server. Before allowing a request containing a session ID cookie to continue through the pipeline, SecureSessionModule validates the cookie by regenerating the MAC from the requestor's IP address, the User-Agent header, and the secret key. If the freshly computed MAC matches the one in the cookie, the MAC is stripped from the cookie and the request is allowed to proceed. If the MACs don't match, SecureSessionModule throws an InvalidSessionException, The Framework's System.Security.Cryptography.HMACSHA1 class makes the task of generating the MAC really quite easy.
- An open source solution is ArpON "Arp handler inspectiON". It is a portable ARP handler which detects and blocks all Man In The Middle attacks through ARP poisoning and spoofing attacks with a static ARP inspection (SARPI) and dynamic ARP inspection (DARPI) approach on switched or hubbed LANs with or without DHCP. This requires an agent on every host that is to be protected.
- Use of a long random number or string as the session key. This reduces the risk that an attacker could simply guess a valid session key through trial and error or brute force attacks.
- Regenerating the session id after a successful login. This prevents session fixation because the attacker does not know the session id of the user after he has logged in.
- Encryption of the data passed between the parties; in particular the session key. This technique is widely relied-upon by web-based banks and other e-commerce services, because it completely prevents sniffing-style attacks. However, it could still be possible to perform some other kind of session hijack.
- Some services make secondary checks against the identity of the user. For example, a web server could check with each request made that the IP address of the user matched the one last used during that session. This does not prevent attacks by somebody who shares the same IP address, however, and could be frustrating for users whose IP address is liable to change during a browsing session.
- Alternatively, some services will change the value of the cookie with each and every request. This dramatically reduces the window in which an attacker can operate and makes it easy to identify whether an attack has taken place, but can cause other technical problems (for example, preventing the back button from working properly, on the web).
- Users may also wish to log out of websites whenever they are finished using them.
Conclusion
Session hijacking remains a serious threat to Networks and Web applications as most of the systems are vulnerable to it. Networks should be tested and monitored continuously in order to make them impenetrable by the intruders.
Building a foolproof (total) security is nearly impossible. Or better still, too costly to adopt reasonably. For example, buying end-to-end encryption may be the only winning complete solution to session hijacking until say, the crypto is broken… which presently, not everybody on the web can afford, too expensive; consider hardware and power requirements for example.
SecureSessionModule raises the bar for hackers who hijack sessions using stolen session IDs by factoring evidence about the session owner into the session ID cookie. That evidence isn't conclusive because neither network addresses nor User-Agent headers can be used reliably to distinguish one user from another, but it nonetheless places an additional hurdle in the path of hackers who are actively seeking to compromise your Web servers by connecting to other users' sessions and grabbing their data.
Web developers have to brave up to the task of appropriately and adequately protecting web sites from session hijacking by finding the appropriate techniques to apply against this perilous practice of session hijackers.
Security is all about raising the bar. The harder you make it for a hacker to execute a successful attack, the less likely it is that successful attacks will occur.
Subscribe to:
Posts (Atom)