Unlock or make to move the disabled or locked Widget in blogger with 6 step process tutorial

                                                   And this post is about to get back the Widgets which are Locked and or not able to move it's position.So follow this few six step process to unlock your widget and you can keep it's position at anywhere.and this is done by own experiment on my blog and succesfully worked process.And i can give you more confidence belive of applying this post.

follow these below steps:

step 1.   Open template's layout.

 step 2.   Look this below image .if you have this same problem.

 step 3.   Copy the name of the Widget you want to Unlock. Like the below image given

 step 4.   Press (ctrl+F)  to open search and paste the widget name their then you will get yellow or your option coloured name.  As shown in below Image 

 step 5.  Replace the " true "  of default to " false". like the below image.

 step 6.  After all this process you will get this successful Moving widget.

                  

And if you wanna to know any further details about Blogger. feel free to comment below

thanx for watching this .Comment below for further details .  and Don't Forget to Like my Facebook page Techno world

Read More

Decorate your comment box as you wish in Blogger

Today I am going to tell you a small trick of changing the Background theme or background according to combination of  your blogger comment box and this post is about to How to Apply Black background theme To blogger Comment Box?  Its very simple just follow these steps: 

Steps:
    1.   Go To Blogger > Design > Edit HTML 
   2.     Backup your template 

    3.   Click the "Expand Widget Templates" box

    4.    Search for this, 

                       ]]></b:skin>

      5.     Just above it paste this code,  for this above effect 

#td-form iframe{ 
background:#ffffff url(https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_ul3DS2dXvVI7Svi9VuIhZIc3BZTR-9oNWO3cmM7la2d57d2eG8uwr9q7cZYxo1Fb_0kcGwBYRey6CTsVl4sdaudTol3mKarmSKCB4SpQdPMM44nYdSP5_E8YVE95YhAGqBpqNKVxmQY/s1600/tech.png) repeat-x; repeat-y;
border:1px solid #ddd; 
-moz-border-radius:6px; 
-webkit-border-radius:6px; 
box-shadow: 5px 5px 5px #CCCCCC; 
padding:5px; 
font:normal 12pt "ms sans serif", Arial; 
color:#2F97FF; 
width:560px; height:213px !important; 
}
#td-form a{ 
color:#fff; 
}

(or)

       5.     for your own image Background,  for this above effect 

#td-form iframe{ 
background:#2aa4cf url(url of your own image) repeat-x; repeat-y;
border:1px solid #ddd; 
-moz-border-radius:6px; 
-webkit-border-radius:6px; 
box-shadow: 5px 5px 5px #CCCCCC; 
padding:5px; 
font:normal 12pt "ms sans serif", Arial; 
color:#ccccc; 
width:560px; height:213px !important; 
}
#td-form a{ 
color:#fff; 
}

for change the color of the text "comment as" simply edit  #2aa4cf   with your own colour and to adjust the width of the box then edit width:560px and Leave other things as it is for better and clean look.

    

   6.    Next search for this, ..press (ctrl + F) for search box 

<div class='comment-form'>

   7.   Replace it  with the code below,

<div id='td-form'>

    8.   Save your template and you are all done!. it's completed .   and also it's a verified process . If you have doubt look below my comment box.

and if you wanna to know any further details about Blogger. feel free to comment below

thanx for watching this .Comment below for further details .  and Don't Forget to Like my Facebook page Techno world 

Read More

Windows 8.1 a Small updates news leaked by Extra Multitasking view

We all know that Windows 8 was running in present market.So due to fast technology update this Microsoft was also going to give this Windows 8 had an update of Windows 8.1 after the news review of Windows Blue. So by the hope of the Microsoft  this extra Multitasking Windows 8.1 updates will going to rock on the Users gadgets .

A new build of Windows 8.1 has surfaced on file sharing networks this week along with a host of screenshots providing a fresh look at Microsoft's plans for its Windows 8 upgrade. Build 9369, a more recent build than the previous leak, includes some tweaks and changes as work continues on Windows 8.1. Microsoft hasn't made any significant changes in this build, but the company appears to be improving the multitasking interface for multiple "Metro-style" applications.

NEW MULTITASKING UI

While the previous build revealed the ability to snap multiple apps, the latest leak includes a new UI element that allows you to pick which view an app opens into. This mode is only enabled when two or more apps are snapped side-by-side, and the new app splash screen simply hovers until an area is selected. Other improvements include a "Files" app with the SkyDrive logo. It's not immediately clear whether this is the result of Microsoft's continued SkyDrive integration, or a separate "Metro" file explorer. Either way, the app includes a touch-friendly interface to navigate local files and content stored on SkyDrive.

Microsoft also appears to be improving its support for keyboard and mouse users. A new apps button is present in the left-hand side of the Start Screen which provides quick access to a list of apps. A new filter is also available to select by "most used" apps. The Search Charm functionality is also altered, allowing users to type a search query and then press enter to search apps or select the relevant search area from the Charm. In Windows 8, this automatically starts searching apps from the Start Screen. A new search setting also allows Windows 8.1 to include search suggestions and results from the web, something we'd previously heard was coming.

Lockscreen camera access was previously discovered, and the UI appears to work in build 9369, allowing users to simply drag down on the lockscreen to access the camera and take photos quickly. Microsoft has also added trackpad settings into the Windows 8-style PC settings page, letting users disable edge gestures. ReFS client support also appears to be present in this latest build, suggesting that Microsoft may be preparing to include its new file system in the final version of Windows 8.1.

NO SURPRISES, JUST REFINEMENTS

Overall there's no huge surprises or changes here. A boot to desktop setting does not appear to be present, and the Start Button is nowhere to be seen. Microsoft is still tweaking Windows 8.1 heavily and the company is expected to release a public preview version at its Build developer conference in June.

these are all the some review content which are leaked by the Microsoft was to share builds to OEMs and partners. This is one of those builds

Read More

Hybrid Hydrogen Rapide S - race car Aston Martin's new four-seat is going to rock on track by " 0 Co2 Emission "

                                          A few weeks ago, Aston Martin announced that they would reveal a prototype of Rapide S with a unique powertrain, here is the first hydrogen Aston Martin!

This prototype is built on the basis of a Rapide S that will arrive in showrooms this month, it has been developed with the help of the company Alset Global and allows a bi-fuel combustion hydrogen or gasoline, as well as the ability to drive with the two energies combined in hybrid mode!

The stated goal is to achieve one lap of the Nurburgring with Zero Emissions!

Dr Ulrich Bez said: “As we celebrate our centenary in 2013 and look back on a century of excitement, innovation and style it’s also the perfect time to look to the future with this astonishing race car.”

Aston Martin is ripping up the record books at the 41st ADAC Zurich 24 Hours of Nürburgring next month as the famous British sports car brand is to race a pioneering hybrid hydrogen car.

The record-breaking Hybrid Hydrogen Rapide S – based on Aston Martin’s new four-door, four-seat sports car – will become the first hydrogen-powered car to compete in an international event as well as the first zero CO2 emissions sports car to complete a race pace lap at the Nürburgring 24-hour race.

The system includes a "fuel rail", storage tanks (4 carbon fiber tanks storing 3.5kg of hydrogen- at 350bars two next to the driver and two in the trunk) and a specific engine management.

For a demonstration of the car we might have to wait for the 24 hours of the Nurburgring which takes place next May 19 and 20! Aston Martin wants to be the first to race with an hydrogen vehicle against combustion cars, cutting the grass under the feet of GreenGT...

Working in partnership with hydrogen experts Alset Global, Aston Martin’s engineers have developed a prototype twin turbocharged 6.0-litre V12 engine that will power the Nürburgring car.

Capable of running on pure gasoline, pure gaseous hydrogen, or a blend of both, the Hybrid Hydrogen race car showcases Aston Martin’s commitment to engineering innovation. In pure hydrogen mode, Aston Martin and Alset Global aim to show that a zero CO2 emissions lap of the Nordschleife is possible while emitting virtually only water from the exhaust.

Showcasing the technology at the Nürburgring – acknowledged as one of the toughest and most demanding circuits in the world and, of course, nicknamed ‘the Green Hell’ – Aston Martin will underline the reliability and safety of today’s hydrogen technology.

Welcoming the debut of the Hybrid Hydrogen Rapide S, Aston Martin Chief Executive Officer Dr Ulrich Bez said: “As we celebrate our centenary in 2013 and look back on a century of excitement, innovation and style it’s also the perfect time to look to the future with this astonishing race car.

“Aston Martin has a strong track record of innovation and, with our superb history of competition and testing at the Nürburgring, it is only right that we showcase this amazing new technology at this year’s 24-hour race.”

He added: “Working with Alset Global to unveil this system in such a challenging environment as the 24 Hours of Nürburgring shows once again how confident we are in our cars, our people and our partners.”

The Hybrid Hydrogen system comprises a hydrogen fuel rail, storage tanks and proprietary engine management system. This enables flexibility in the control of the combustion process according to each particular driving situation: either pure hydrogen, gasoline or a arbitrary blend of both can be selected to ensure optimum power, acceleration and CO2 reduction. This control results in a powerful and dynamic propulsion system that provides sports car performance but with a carbon footprint more akin to that of a supermini.

(sourceby technologyvehilces)

Safety is paramount, of course, and the system includes four ultra-high strength carbon fibre tanks holding a total of 3.5kg of hydrogen stored at a pressure of 350bar – two tanks housed next to the driver and two in the boot of the car. Meanwhile the entire hydrogen system developed by Alset Global and its partners is approved by German motorsport’s governing body, the DMSB.

The Hybrid Hydrogen race car is based on the new Rapide S four-door sports car that is arriving in Aston Martin showrooms worldwide this month.

Redesigned and re-engineered to offer even greater style and significantly enhanced performance by virtue of its new AM11 6.0-litre V12 naturally aspirated engine, the new Rapide S is capable of 190 mph and sprints from 0 to 62 mph in only 4.9 seconds.

Dr Bez said of the new road car: “It is a four-door sports car that uniquely combines luxury, style and sporting excitement in Aston Martin’s most flexible and accommodating silhouette. This is the four-door sports car in its most versatile form.”

Aston Martin returns to compete in the ADAC Zurich Nürburgring 24 Hours on May 19-20 for the eight successive year. More than 150 cars will start the fearsome 24-hour race, which runs on the daunting 25km circuit that combines the legendary Nordschleife with the modern Grand Prix track.

Comment below for further details .  and Don't Forget to Like my Facebook page Techno world 

Read More

Newborn Facebook Home had modified to work on all Android devices by H@CKERs

Almost of all know about Facebook Home almost. but this post is related to it's negative end that it's just Hacked in the way that removing it's limit of Usability on specified mobiles.So after this Hack it was modded FB Home to run on all  devices, without touching build.prop or requiring root . Tested on GNEX, NEXUS 7 emulators.

Actual FB Home front end details of one side:

Facebook Home is the mobile experience that puts your friends at the heart of your phone. From the moment you turn it on, you see a steady stream of friends' posts and photos on your home screen. Upfront notifications and quick access to your essentials mean you'll never miss a moment. And when you download Facebook Messenger, you can keep chatting with friends when you're using other apps.

What's in this version:

• Glance at your phone for the latest photos and posts from your friends

• With chat heads and Facebook Messenger, you can keep chatting when you’re using other apps

• See news as it happens with bigger, bolder notifications

• Get right to Facebook, Instagram and other essentials

Install the latest Messenger and Facebook apps for the full Home experience.
• Facebook Messenger: http://bit.ly/fbandroidmessenger
• Facebook for Android: http://bit.ly/fbandroidapp

Cover Feed
As soon as you turn on your phone, you see posts from your News Feed, so you always know what your friends are up to. Swipe through to see more, double tap to like a post, and comment right from cover feed.

Chat Heads and Messenger
Install Messenger to send and receive texts and Facebook messages from the same spot. Jump in and out of conversations while you do other things, like watch videos and browse the web. Reply right from chat heads, or move them around if you're not ready to respond.http://bit.ly/fbandroidmessenger

Notifications
Notifications from Facebook appear right on your home screen and stick around until you need them. Open a notification with a tap or clear them away to see your cover feed.

App Launcher
Launch your favorite apps and post to Facebook from the same spot. You choose what’s on your app launcher—press and hold an app then drag it where you want it

It's  Term to it's Hacked face of a Facebook Home details :

Within few hours after Facebook Home arrived on Google Play, hackers from XDA forum have launched a modified version of Facebook Home that would remove the device-specific limitation. In other words, you can now use Facebook Home on any Android device. Facebook Home is currently available only to these devices – HTC One X, One X+, Samsung Galaxy S III, Galaxy Note II, and the HTC First.

The hack was performed by XDA Senior Member theos0o; who provides details and download links here. The hacker says there is no root needed for this hack. However you will have to uninstall original Facebook, Facebook messenger and Facebook home apps. If Facebook is pre-installed then you probably need root to remove it.

To download this modified version of Facebook home, please visit XDA Developers forum.

Comment below for further details .  and Don't Forget to Like my Facebook page Techno world 

Read More

A small view about Parameter Manipulation attack like Hacking

Parameter Manipulation ?

Manipulating the data sent between the browser and the web application to an attacker's advantage has long been a simple but effective way to make applications do things in a way the user often shouldn't be able to. In a badly designed and developed web application, malicious users can modify things like prices in web carts, session tokens or values stored in cookies and even HTTP headers. 

No data sent to the browser can be relied upon to stay the same unless cryptographically protected at the application layer. Cryptographic protection in the transport layer (SSL) in no way protects one from attacks like parameter manipulation in which data is mangled before it hits the wire. Parameter tampering can often be done with: 

• Cookies
• Form Fields
• URL Query Strings
• HTTP Headers

Cookie Manipulation ?

Description

Cookies are the preferred method to maintain state in the stateless HTTP protocol. They are however also used as a convenient mechanism to store user preferences and other data including session tokens. Both persistent and non-persistent cookies, secure or insecure can be modified by the client and sent to the server with URL requests. Therefore any malicious user can modify cookie content to his advantage. There is a popular misconception that non-persistent cookies cannot be modified but this is not true; tools like Winhex are freely available. SSL also only protects the cookie in transit.

The extent of cookie manipulation depends on what the cookie is used for but usually ranges from session tokens to arrays that make authorization decisions. (Many cookies are Base64 encoded; this is an encoding scheme and offers no cryptographic protection).
Example from a real world example on a travel web site modified to protect the innocent (or stupid).

   Cookie: lang=en-us; ADMIN=no; y=1 ; time=10:30GMT ;
   

The attacker can simply modify the cookie to;

   Cookie: lang=en-us; ADMIN=yes; y=1 ; time=12:30GMT ;
   

Mitigation Techniques ?

One mitigation technique is to simply use one session token to reference properties stored in a server-side cache. This is by far the most reliable way to ensure that data is sane on return: simply do not trust user input for values that you already know. When an application needs to check a user property, it checks the userid with its session table and points to the users data variables in the cache / database. This is by far the correct way to architect a cookie based preferences solution.

Another technique involves building intrusion detection hooks to evaluate the cookie for any infeasible or impossible combinations of values that would indicate tampering. For instance, if the "administrator" flag is set in a cookie, but the userid value does not belong to someone on the development team.

The final method is to encrypt the cookie to prevent tampering. There are several ways to do this including hashing the cookie and comparing hashes when it is returned or a symmetric encryption , although server compromise will invalidate this approach and so response to penetration must include new key generation under this scheme.

HTTP Header Manipulation ?

Description

HTTP headers are control information passed from web clients to web servers on HTTP requests, and from web servers to web clients on HTTP responses. Each header normally consists of a single line of ASCII text with a name and a value. Sample headers from a POST request follow.

Host: www.someplace.org
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Lynx/2.8.4dev.9 libwww-FM/2.14
Referer: http://www.someplace.org/login.php
Content-type: application/x-www-form-urlencoded
Content-length: 49
   

Often HTTP headers are used by the browser and the web server software only. Most web applications pay no attention to them. However some web developers choose to inspect incoming headers, and in those cases it is important to realize that request headers originate at the client side, and they may thus be altered by an attacker.

Normal web browsers do not allow header modification. An attacker will have to write his own program (about 15 lines of perl code will do) to perform the HTTP request, or he may use one of several freely available proxies that allow easy modification of any data sent from the browser.

Example 1: The Referer header (note the spelling), which is sent by most browsers, normally contains the URL of the web page from which the request originated. Some web sites choose to check this header in order to make sure the request originated from a page generated by them, for example in the belief it prevents attackers from saving web pages, modifying forms, and posting them off their own computer. This security mechanism will fail, as the attacker will be able to modify the Referer header to look like it came from the original site.

Example 2: The Accept-Language header indicates the preferred language(s) of the user. A web application doing internationalization (i18n) may pick up the language label from the HTTP header and pass it to a database in order to look up a text. If the content of the header is sent verbatim to the database, an attacker may be able to inject SQL commands (see SQL injection) by modifying the header. Likewise, if the header content is used to build a name of a file from which to look up the correct language text, an attacker may be able to launch a path traversal attack.

Mitigation Techniques ?

Simply put headers cannot be relied upon without additional security measures. If a header originated server-side such as a cookie it can be cryptographically protected. If it originated client-side such as a referer it should not be used to make any security decisions.

Further Reading

For more information on headers, please see RFC 2616 which defines HTTP/1.1.

HTML Form Field Manipulation ?

Description

When a user makes selections on an HTML page, the selection is typically stored as form field values and sent to the application as an HTTP request (GET or POST). HTML can also store field values as Hidden Fields, which are not rendered to the screen by the browser but are collected and submitted as parameters during form submissions.

Whether these form fields are pre-selected (drop down, check boxes etc.), free form or hidden, they can all be manipulated by the user to submit whatever values he/she chooses. In most cases this is as simple as saving the page using "view source", "save", editing the HTML and re-loading the page in the web browser.

As an example an application uses a simple form to submit a username and password to a CGI for authentication using HTTP over SSL. The username and password form fields look like this.

  

Some developers try to prevent the user from entering long usernames and passwords by setting a form field value maxlength=(an integer) in the belief they will prevent the malicious user attempting to inject buffer overflows of overly long parameters. However the malicious user can simply save the page, remove the maxlength tag and reload the page in his browser. Other interesting form fields include disabled, readonly and value. As discussed earlier, data (and code) sent to clients must not be relied upon until in responses until it is vetted for sanity and correctness. Code sent to browsers is merely a set of suggestions and has no security value.

Hidden Form Fields represent a convenient way for developers to store data in the browser and are one of the most common ways of carrying data between pages in wizard type applications. All of the same rules apply to hidden forms fields as apply to regular form fields.
Example 2 - Take the same application. Behind the login form may have been the HTML tag;

 <input name="masteraccess" type="hidden" value="N">
   

By manipulating the hidden value to a Y, the application would have logged the user in as an Administrator. Hidden form fields are extensively used in a variety of ways and while it's easy to understand the dangers they still are found to be significantly vulnerable in the wild.

Mitigation Techniques ?

Instead of using hidden form fields, the application designer can simply use one session token to reference properties stored in a server-side cache. When an application needs to check a user property, it checks the session cookie with its session table and points to the user's data variables in the cache / database. This is by far the correct way to architect this problem.

If the above technique of using a session variable instead of a hidden field cannot be implemented, a second approach is as follows.

The name/value pairs of the hidden fields in a form can be concatenated together into a single string. A secret key that never appears in the form is also appended to the string. This string is called the Outgoing Form Message. An MD5 digest or other one-way hash is generated for the Outgoing Form Message. This is called the Outgoing Form Digest and it is added to the form as an additional hidden field.

When the form is submitted, the incoming name/value pairs are again concatenated along with the secret key into an Incoming Form Message. An MD5 digest of the Incoming Form Message is computed. Then the Incoming Form Digest is compared to the Outgoing Form Digest (which is submitted along with the form) and if they do not match, then a hidden field has been altered. Note, for the digests to match, the name/value pairs in the Incoming and Outgoing Form Messages must concatenated together in the exact same order both times.

This same technique can be used to prevent tampering with parameters in a URL. An additional digest parameter can be added to the URL query string following the same technique described above.

URL Manipulation ?

Description

URL Manipulation comes with all of the problems stated above about Hidden Form Fields, and creates some new problems as well.

HTML Forms may submit their results using one of two methods: GET or POST. If the method is GET, all form element names and their values will appear in the query string of the next URL the user sees. Tampering with hidden form fields is easy enough, but tampering with query strings is even easier. One need only look at the URL in the browser's address bar.

Take the following example; a web page allows the authenticated user to select one of his pre-populated accounts from a drop-down box and debit the account with a fixed unit amount. It's a common scenario. His/her choices are recorded by pressing the submit button. The page is actually storing the entries in form field values and submitting them using a form submit command. The command sends the following HTTP request. 

http://www.victim.com/example?accountnumber=12345&debitamount=1
   

A malicious user could construct his own account number and change the parameters as follows:

http://www.victim.com/example?accountnumber=67891&creditamount=999999999   

Thee new parameters would be sent to the application and be processed accordingly.

This seems remarkably obvious but has been the problem behind several well-published attacks including one where hackers bought tickets from the US to Paris for $25 and flew to hold a hacking convention. Another well-known electronic invitation service allowed users to guess the account ID and login as a specific user this way; a fun game for the terminally bored with voyeuristic tendencies.

Unfortunately, it isn't just HTML forms that present these problems. Almost all navigation done on the internet is through hyperlinks. When a user clicks on a hyperlink to navigate from one site to another, or within a single application, he is sending GET requests. Many of these requests will have a query string with parameters just like a form. And once again, a user can simply look in the "Address" window of his browser and change the parameter values.

Mitigation Techniques ?

Solving URL manipulation problems takes planning. Different techniques can be used in different situations. The best solution is to avoid putting parameters into a query string (or hidden form field).

When parameters need to be sent from a client to a server, they should be accompanied by a valid session token. The session token may also be a parameter, or a cookie. Session tokens have their own special security considerations described previously. In the example above, the application should not make changes to the account without first checking if the user associated with the session has permission to edit the account specified by the parameter "accountnumber". The script that processes a credit to an account cannot assume that access control decisions were made on previous application pages. Parameters should never be operated on unless the application can independently validate they were bound for and are authorized to be acted on.

However, a second form of tampering is also evident in the example. Notice that the creditamount is increased from 1 to 999999999. Imagine that the user doesn't tamper with the accountnumber but only with the amount. He may be crediting his own account with a very large sum instead of $1. Clearly this is a parameter that should simply not be present in the URL.

There are two reasons why a parameter should not be a URL (or in a form as a hidden field). The above example illustrates one reason - the parameter is one the user should not be able to set the value of. The second is if a parameter is one the user should not be able to see the value of. Passwords are a good example of the latter. Users's should not even see their own passwords in a URL because someone may be standing behind them and because browsers record URL histories. See Browser History Attack.

If a sensitive parameter cannot be removed from a URL, it must be cryptographically protected. Cryptographic protection can be implemented in one of two ways. The better method is to encrypt an entire query string (or all hidden form field values). This technique both prevents a user from setting the value and from seeing the value.

A second form of cryptographic protection is to add an additional parameter whose value is an MD5 digest of the URL query string (or hidden form fields) More details of this technique are described above in the section "HTML Form Field Manipulation". This method does not prevent a user from seeing a value, but it does prevent him from changing the value. 

Miscellaneous ?

Vendors Patches

Vulnerabilities are common within 3rd party tools and products that are installed as part of the web applications. These web-server, application server, e-comm suites, etc. are purchased from external vendors and installed as part of the site. The vendor typically addresses such vulnerabilities by supplying a patch that must be downloaded and installed as an update to the product at the customer's site.

A significant part of the web application is typically not customized and specific for a single web site but rather made up of standard products supplied by 3rd party vendors. Typically such products serve as the web server, application server, databases and more specific packages used in the different vertical markets. All such products have vulnerabilities that are discovered in an ongoing manner and in most cases disclosed directly to the vendor (although there are also cases in which the vulnerability is revealed to the public without disclosure to the vendor). The vendor will typically address the vulnerability by issuing a patch and making it available to the customers using the product, with or without revealing the full vulnerability. The patches are sometimes grouped in patch groups (or updates) that may be released periodically.

A vendors disclosure policy of vulnerabilities is of primary concern to those deploying ciritcal systems. Those in a procurement position should be very aware of the End User License Agreements (EULAs) under which vendors license their software. Very often these EULAs disclaim all liability on the part of the vendor, even in cases of serious neglect, leaving users with little or no recourse. Those deploying software distributed under these licenses are now fully liable for damage caused by the defects that may be a part of this code. Due to this state of affairs, it becomes ever more important that orginizations insist upon open discussion and disclosure of vulnerabilities in the software they deploy. Vendors have reputations at stake when new vulnerabilities are disclosed and many attempt to keep such problems quiet, thereby leaving their clients without adequate information in asessing their exposure to threats. This behaviour is unacceptable in a mature software industry and should not be tollerated. Furthermore, orginizations should take care to ensure that vendors do not attempt to squelch information needed to verify the validity and effectiveness of patches. While this might seem a frivilous concern at first glance, vendors have been known to try to limit distribution of this information in order to provide "security" through obscurity. Customers may be actively harmed in the meanwhile as Black Hats have more information about a problem than White Hats do, again imparing an organizations ability to assess its risk exposure.

The main issue with vendor patches is the latency between the disclosure of the vulnerability to the actual deployment of the patch in the production environment i.e. the patch latency and the total time needed to issue the patch by the vendor, download of the patch by the client, test of the patch in a QA or staging environment and finally full deployment in the production site. During all this time the site is vulnerable to attacks on this published vulnerability. This results in misuse of the patch releases to achieve opposite results by humans and more recently by worms such as CodeRed.

Most patches are released by the vendors only in their site and in many cases published only in internal mailing lists or sites. Sites and lists following such vulnerabilities and patches (such as bugtraq) do not serve as a central repository for all patches. The number of such patches for mainstream products is estimated at dozens a month.

The final critical aspect of patches is that they are not (in most cases) signed or containing a checksum causing them to be a potential source of Trojans in the system.

You should subscribe to vendors' security intelligence service for all software that forms part of your web application or a security infrastructure.

System Configuration

Server software is often complex, requiring much understanding of both the protocols involved and their internal workings to correctly configure. Unfortunantly software makes this task much more difficult by providing default configurations which are known to be vulnerable to devastating attacks. Often "sample" files and directories are installed by default which may provide attackers with ready-made attacks should problems be found in the sample files. While many vendors suggest removing these files by default, they put the onus of securing an "out of the box" installation on those deploying their product. A (very) few vendors attempt to provide secure defaults for their systems (the OpenBSD project being an example). Systems from these vendors often prove much less vulnerable to widespread attack, this approach to securing infrastructure appears to work very well and should be encouraged when discussing procurement with vendors.

If a vendor provides tools for managing and securing installations for your software, it may be worth evaluating these tools, however they will never be a full replacement for understanding how a system is designed to work and strictly managing configurations across your deployed base.

Understanding how system configuration affects security is crucial to effective risk management. Systems being deploying today rely on so many layers of software that a system may be compromised from vectors which may be difficult or impossible to predict. Risk management and threat analysis seeks to quantify this risk, minimize the impact of the inevitable failure, and provide means (other than technical) for compensating for threat exposure. Configuration management is a well understood piece of this puzzle, yet remains maddeningly difficult to implement well. As configurations and environmental factors may change over time, a system once well shielded by structural safeguards may become a weak link with very little outward indication that the risk inherent in a system has changed. Organizations will have to accept that configuration management is a continuing process and cannot simply be done once and let be. Effectively managing configurations can be a first step in putting in place the safeguards that allow systems to perform reliably in the face of concerted attack.

Comments in HTML ?

Description

It's amazing what one can find in comments. Comments placed in most source code aid readability and improve documented process. The practice of commenting has been carried over into the development of HTML pages, which are sent to the clients' browser. As a result information about the structure of the a web site or information intended only for the system owners or developers can sometimes be inadvertently revealed.

Comments left in HTML can come in many formats, some as simple as directory structures, others inform the potential attacker about the true location of the web root. Comments are sometimes left in from the HTML development stage and can contain debug information, cookie structures, problems associated with development and even developer names, emails and phone numbers.

Structured Comments - these appear in HTML source, usually at the top of the page or between the JavaScript and the remaining HTML, when a large development team has been working on the site for some time.

Automated Comments - many widely used page generation utilities and web usage software automatically adds signature comments into the HTML page. These will inform the attacker about the precise software packages (sometimes even down to the actual release) that is being used on the site. Known vulnerabilities in those packages can then be tried out against the site.

Unstructured Comments - these are one off comments made by programmers almost as an "aid memoir" during development. These can be particularly dangerous as they are not controlled in any way. Comments such as "The following hidden field must be set to 1 or XYZ.asp breaks" or "Don't change the order of these table fields" are a red flag to a potential attacker and sadly not uncommon.

Mitigation Techniques ?

For most comments a simple filter that strips comments before pages are pushed to the production server is all that is required. For Automated Comments an active filter may be required. It is good practice to tie the filtering process to sound deployment methodologies so that only known good pages are ever released to production.

Old, Backup and Un-referenced Files ?

Description

File / Application Enumeration is a common technique that is used to look for files or applications that may be exploitable or be useful in constructing an attack. These include known vulnerable files or applications, hidden or un-referenced files and applications and back-up / temp files.

File /Application enumeration uses the HTTP server response codes to determine if a file or application exists. A web server will typically return an HTTP 200 response code if the file exists and an HTTP 404 response code if the file does not exist. This enables an attacker to feed in lists of known vulnerable files and suspected applications or use some basic logic to map the file and application structure visible from the presentation layer.

Known Vulnerable Files - Obviously many known vulnerable files exist, and in fact looking for them is one of the most common techniques that commercial and free-ware vulnerability scanners use. Many people will focus their search on cgi's for example or server specific issues such as IIS problems. Many daemons install "sample" code in publicly accessible locations, which are often found to have security problems. Removing (or simply not installing) such default files cannot be recommended highly enough.

Hidden / Un-Referenced Files - Many web site administrators leave files on the web server such as sample files or default installation files. When the web content is published, these files remain accessible although are un-referenced by any HTML in the web. Many examples are notoriously insecure, demonstrating things like uploading files from a web interface for instance. If an attacker can guess the URL, then he is typically able to access the resource.

Back-Up Files / Temp Files - Many applications used to build HTML and things like ASP pages leave temp files and back-up files in directories. These often get up-loaded either manually in directory copies or automagically by site management modules of HTML authoring tools like Microsoft's Frontpage or Adobe Go-Live. Back-up files are also dangerous as many developers embed things into development HTML that they later remove for production. Emacs for instance writes a *.bak in many instances. Development staff turnover may also be an issue, and security through obscurity is always an ill-advised course of action.

Mitigation Techniques ?

Remove all sample files from your web server. Ensure that any unwanted or unused files are removed. Use a staging screening process to look for back-up files. A simple recursive file grep of all extensions that are not explicitly allowed is very effective.

Some web server / application servers that build dynamic pages will not return a 404 message to the browser, but instead return a page such as the site map. This confuses basic scanners into thinking that all files exist. Modern vulnerability scanners however can take a custom 404 and treat it as a vanilla 404 so this technique only slows progress.

Debug Commands ?

Description

Debug commands actually come in two distinct forms
Explicit Commands - this is where a name value pair has been left in the code or can be introduced as part of the URL to induce the server to enter debug mode. Such commands as "debug=on" or

"Debug=YES" can be placed on the URL like:

http://www.somewebsite.com/account_check?ID=8327dsddi8qjgqllkjdlas&Disp=no
   

Can be altered to:

http://www.somewebsite.com/account_check?debug=on&ID=8327dsddi8qjgqllkjdlas&Disp=no
   

The attacker observes the resultant server behavior. The debug construct can also be placed inside HTML code or JavaScript when a form is returned to the server, simply by adding another line element to the form construction, the result is the same as the command line attack above.

Implicit Commands - this is where seemingly innocuous elements on a page if altered have dramatic effects on the server. The original intent of these elements was to help the programmer modify the system into various states to allow a faster testing cycle time. These element are normally given obscure names such as "fubar1" or "mycheck" etc. These elements may appear in the source as: 

<!-- begins -->
<TABLE BORDER=0 ALIGN=CENTER CELLPADDING=1 CELLSPACING=0>>
<FORM METHOD=POST ACTION="http://some_poll.com/poll?1688591" TARGET="sometarget" FUBAR1="666">
<INPUT TYPE=HIDDEN NAME="Poll" VALUE="1122">
<!-- Question 1 -->
<TR>
<TD align=left colspan=2>
<INPUT TYPE=HIDDEN NAME="Question" VALUE="1">
<SPAN class="Story">
   

Finding debug elements is not easy, but once one is located it is usually tried across the entire web site by the potential hacker. As designers never intend for these commands to be used by normal users, the precautions preventing parameter tampering are usually not taken.

Debug commands have been known to remain in 3rd party code designed to operate the web site, such as web servers, database programs. Search the web for "Netscape Engineers are weenies" if you don't believe us!

Default Accounts ?

Description

Many "off the shelf" web applications typically have at least one user activated by default. This user, which is typically the administrator of the system, comes pre-configured on the system and in many cases has a standard password. The system can then be compromised by attempting access using these default values.

Web applications enable multiple default accounts on the system, for example: 

• Administrator accounts
• Test accounts
• Guest accounts

The accounts can be accessed from the web either using the standard access for all defined account or via special ports or parts of the application, such as administrator pages. The default accounts usually come with pre-configured default passwords whose value is widely known. Moreover, most applications do not force a change to the default password.

The attack on such default accounts can occur in two ways: 

• Attempt to use the default username/password assuming that it was not changed during the default installation.
• Enumeration over the password only since the user name of the account is known.

Once the password is entered or guessed then the attacker has access to the site according to the account's permissions, which usually leads in two major directions:

If the account was an administrator account then the attacker has partial or complete control over the application (and sometimes, the whole site) with the ability to perform any malicious action.

If the account was a demo or test account the attacker will use this account as a means of accessing and abusing the application logic exposed to that user and using it as a mean of progressing with the attack.

Mitigation Techniques ?

Always change out of the box installation of the application. Remove all unnecessary accounts, following security checklist, vendor or public. Disable remote access to the admin accounts on the application. Use hardening scripts provided by the application vendors and vulnerability scanners to find the open accounts before someone else does.copy source by (blackhatcrackers.blogspot)

Comment below for further details .  and Don't Forget to Like my Facebook page Techno world 

as usually this post is for completely educational purpose  and I did not take any responsibility of any misuse, Hacking email accounts is criminal activity and is punishable under cyber crime and you may get upto 40 years of imprisonment, if got caught in doing so. you will be solely responsible for any misuse that you do.

Read More