Thu 11 Dec 2008

Being a facebook developer, following information will be helpful for users.

Privacy is always an important factor in personal life and behaving.

If any female or male doesn't want to share his or her photos or albums on facebook with unknown personals, which are vulnerable to misbehavers, then don't forget to set its privacy setting at following locations :-  Click on

1) Settings (from top facebook menu -> Privacy Setting -> Profile -> Edit Photo Albums Privacy Settings

2) Settings (from top facebook menu -> Privacy Setting -> Profile -> Photo Tagged of You

You may set its value of who can see this to Only Friends or Lower Custom Settings.

 

Are you sure you want to share your photos and personal information to persons who you dont know and to strangers?, If no then set your privacy settings now!

  


 

facebook privacy setting 1.jpg

 


 

 facebook privacy setting 4.JPG

 


 

 


facebook privacy setting 2.JPG

 



facebook privacy setting 3.JPG

 

For Facebook privacy settings - applications, click following link
http://faisal.azmza.com/post/Facebook-Privacy-Setting-Applications.aspx

Comments (3)
Mon 1 Dec 2008

HAARP - More than 200 miles east of Anchorage, Alaska, is the Pentagon's High-frequency Active Auroral Research Program, officially an enormous experiment to heat the ionosphere with radio waves. But conspiracy theorists believe the project is a weapon to bring down aircraft and missiles by lifting sections of the atmosphere, cause earthquakes or even a huge weather modification machine.

Source - telegraph.co.uk

haarp_1116124i.jpg

Categories : Knowledge / Amazing
Comments here
Thu 27 Nov 2008

KARACHI: In what seems to be an intensifying cyber war between hackers of Pakistan and India, Pakistani hackers managed to hack website of ONGC (Oil and Natural Gas Corporation) of India on Tuesday.

A group named ‘Pakistan Cyber Army’ (PCA) said that it hacked Indian ONGC website in response to hacking of the website of Pakistan’s OGRA (Oil and Gas Regulatory Authority) by Indian hackers.

Sites hacked among are CID Andhra Pardesh India, India Rail, Indian ONGC.

 Reference : thenews.com.pk/updates.asp?id=60966

 india_pakistan_websites_hacked_by_indian_pakistani_hacking.jpg

Comments here
Tue 7 Oct 2008

The smallest robot ever in the world, trust me you wont see it even if it is with you in the same room

 

smallest robot image014a.jpg

Comments here
Wed 16 Jul 2008

Quantum information technology

Enigma variations

Jul 10th 2008
From The Economist print edition

Quantom atricle.jpg

A device that counts photons will secure optical data networks from prying eyes

REMOVE the outer coating from a strand of optical fibre, bend it and attach a sensor to detect the tiny amount of light that will leak out. Hacking into an optical network like this is the modern equivalent of a wire tap. But now a laboratory in Cambridge, England, has found a way to turn a hacker’s screen instantly blank if he infiltrates the network. This is because the data are being encrypted in a new and probably unbreakable way with one of the first practical devices to be developed for quantum information technology.

The idea of using the more arcane aspects of quantum theory to do things that standard information technology cannot manage has been around for a while. One branch of the field is quantum computing. This, if it can be made to work routinely, promises machines that can do lots of calculations in parallel instead of one at a time, and thus solve problems existing computers cannot manage. The other branch is quantum cryptography, which promises unbreakable codes for messages.

Q’s laboratory

The device in question is a photon detector. That is not very exciting by itself, but this detector counts single photons (the particles of which light is composed)—and can do so at room temperature. Most quantum systems are upset by heat. Orion, for example, operates near absolute zero, and previous attempts to build single-photon detectors have suffered similar constraints. Dr Shields’s device, however, is a simple modification of the sort of equipment that is already used to detect multiple photons, and should thus be easy to deploy.

Such devices, known as avalanche photodiodes, rely on the fact that when a photon hits a semiconductor it often knocks an electron out of place, creating a positively charged “hole” in the crystal lattice in the place where the negatively charged electron used to be. If an electric charge is applied to the crystal, these holes and electrons will move in opposite directions, knocking into the lattice and creating more and more holes. The resulting cascade of electrons and holes is easy to detect, showing that light has struck.

What is not easy to work out is exactly how many photons have arrived. To do that, you need to look at the signal just after it has been created, when its size bears some relation to the number of holes that started it. At that point, though, the signal is small compared with the electronic “noise” caused by the machine’s operation. What Dr Shields did was to work out a way of subtracting the noise, and thus extracting the signal.

Such a photon counter is essential if quantum cryptography is to work, because it will allow what are known as quantum repeaters to be built. In a classical telecommunications system the signal has to be boosted by a repeater every 80km or so. But a traditional repeater destroys the quantum states of the photons, such as their planes of polarisation. That does not matter for classical telecoms, but matters very much for quantum cryptography, which relies on the fact that no eavesdropper can intercept the message without changing those quantum states, and thus giving away the fact that he is on the line.

Dr Shields’s photon detector, however, permits cryptographers to use a phenomenon called quantum entanglement to make a repeater that does not destroy quantum states. Entangled photons share quantum states.

Such a quantum repeater uses groups of three photons for each bit of the message. One—call it A—is part of the original transmission. The other two, B and C, are created further down the line in an entangled state, and sent off in different directions. C goes to the recipient while B is fed into a device called a beam-splitter, where it meets A. The purpose of the beam-splitter is to compare the quantum states of A and B. If they are the same, the two photons will come out of the beam-splitter together. Since B and C have the same quantum states, that means C also has the same quantum state as A. If A and B are different, they will come out of the beam-splitter in one of three different places, depending on exactly which way they are different. The information from the beam-splitter is then transmitted separately to the recipient, so that he knows whether to accept C unaltered as part of the message, or apply one of three mathematical transformations to it, to arrive at the right result (this does not compromise secrecy, since any eavesdropper will not know what the transformation needs to be applied to). It is for this reason that you need a device, such as Dr Shields’s, which can detect and count individual photons as they come out of different parts of the beam-splitter. Now that there is one, the eavesdropper’s days may be numbered.

Source : http://www.economist.com/science/displayStory.cfm?source=hptextfeature&story_id=11703138

 

Comments here
Fri 4 Jul 2008

Web Service Security using SOAP Extension

 

Yesterday I was trying to secure my webserice from unauthorized use.

Although there are many ways to secure webservices. Using WSE, WS-security, SOAP Extension, restricting through IP access, implementing certificates etc etc etc.

 

WSE would be the comfortable way but in my case it was time consuming to implement at both server and client end as there were hundreds of services. Restricting IP throu IIS or http handler / modules would be a good choice. I tried to do it with SOAP Extension that could be plug and play with a single entry in web.config. It works like httpmodule that reside in pipeline of communication between client and server.

 

Here after enough googling I have a very simple SOAP Extension that would help anyone if just want to secure service that request is coming from authenticated source. Although there would be still many security breaches but here you go.

 

 

What this SOAP extension will do?

Before passing request to webserver, this extension will add a string or any unique token to header of SOAP message then will pass it over network. Before server entertain the request it will look for that token or string in the header of incoming SOAP message request. If exsit then will allow to consume service else will throw an exception or whatever the action depending upon scenario.

 

 

SOAP Message Lifecycle.

 

Client = Going to accessing service

Server = Where service exists and entertaining client request.

 

 

SOAPExtension Life.gif

 

Client side

1.    A client invokes a method on the proxy class.

2.    A new instance of the SOAP extension is created on the client.

3.    If this is the first time this SOAP extension has executed with this XML Web service on the client, then the GetInitializer method is invoked on the SOAP extension running on the client.

4.    The Initialize method is invoked.

5.    The ChainStream method is invoked.

6.    The ProcessMessage method is invoked with the SoapMessageStage set to BeforeSerialize.

7.    ASP.NET on the client computer serializes the arguments of the XML Web service method into XML.

8.    The ProcessMessage method is invoked with the SoapMessageStage set to AfterSerialize.

9.    ASP.NET on the client computer sends the SOAP message over the network to the Web server hosting the XML Web service.

 

Server side

1.    ASP.NET on the Web server receives the SOAP message.

2.    A new instance of the SOAP extension is created on the Web server.

3.    On the Web server, if this is the first time this SOAP extension has executed with this XML Web service on the server side, the GetInitializer method is invoked on the SOAP extension running on the server.

4.    The Initialize method is invoked.

5.    The ChainStream method is invoked.

6.    The ProcessMessage method is invoked with the SoapMessageStage set to BeforeDeserialize.

7.    ASP.NET deserializes the arguments within the XML.

8.    The ProcessMessage method is invoked with the SoapMessageStage set to AfterDeserialize.

9.    ASP.NET creates a new instance of the class implementing the XML Web service and invokes the XML Web service method, passing in the deserialized arguments. This object resides on the same computer as the Web server.

10.  The XML Web service method executes its code, eventually setting the return value and any out parameters.

11.  The ProcessMessage method is invoked with the SoapMessageStage set to BeforeSerialize.

12.  ASP.NET on the Web server serializes the return value and out parameters into XML.

13.  The ProcessMessage method is invoked with the SoapMessageStage set to AfterSerialize.

14.  ASP.NET sends the SOAP response message over the network back to the XML Web service client.

 

Client side

1.    ASP.NET on the client computer receives the SOAP message.

2.    The ProcessMessage method is invoked with the SoapMessageStage set to BeforeDeserialize.

3.    ASP.NET deserializes the XML into the return value and any out parameters.

4.    The ProcessMessage method is invoked with the SoapMessageStage set to AfterDeserialize.

5.    ASP.NET passes the return value and any out parameters to the instance of the proxy class.

6.    The client receives the return value and any out parameters.

 

 

Here what exactly the code contains.

There are three classes.

MyHeader.cs

That will contain our security token or string that server will be looking for.

 

using System;

using System.Collections.Generic;

using System.Text;

using System.Web.Services.Protocols;

using System.Xml.Serialization;

 

    [Serializable]

    public class MyHeader : SoapHeader

    {

        private string _MyHeaderValue;

 

        public string MyHeaderValue

        {

            get { return _MyHeaderValue; }

            set { _MyHeaderValue = value; }

        }

    }

 

 

MySOAPExtensionClient.cs

SOAP Extension that will add security token in header header to outgoing SOAP message

 

using System;

using System.Web.Services;

using System.Web.Services.Protocols;

using System.IO;

using System.Net;

using System.Diagnostics;

 

    public class MySOAPExtensionClient : System.Web.Services.Protocols.SoapExtension

    {

        Stream oldStream;

        Stream newStream;

 

        public override object GetInitializer(LogicalMethodInfo methodInfo, SoapExtensionAttribute attribute)

        {

            return null;

        }

 

        public override object GetInitializer(Type WebServiceType)

        {

            return null;

        }

 

        public override void Initialize(object initializer)

        {

            return;

        }

 

        // Save the Stream representing the SOAP request or SOAP response into

        // a local memory buffer.

        public override Stream ChainStream(Stream stream)

        {

            oldStream = stream;

            newStream = new MemoryStream();

            return newStream;

        }

 

        public override void ProcessMessage(SoapMessage message)

        {

            switch (message.Stage)

            {

                case SoapMessageStage.BeforeSerialize:

                    if (message is SoapClientMessage)

                        AddHeader(message);

                    break;

                case SoapMessageStage.AfterSerialize:

                    newStream.Position = 0;

                    Copy(newStream, oldStream);

                    break;

                case SoapMessageStage.BeforeDeserialize:

                    Copy(oldStream, newStream);

                    newStream.Position = 0;

                    break;

                case SoapMessageStage.AfterDeserialize:

                    break;

            }

        }

 

        private void AddHeader(SoapMessage message)

        {

            MyHeader header = new MyHeader();

            header.MyHeaderValue = "MyValue";

            header.MustUnderstand = false;

            message.Headers.Add(header);

        }

 

        private void Copy(Stream from, Stream to)

        {

            TextReader reader = new StreamReader(from);

            TextWriter writer = new StreamWriter(to);

            writer.WriteLine(reader.ReadToEnd());

            writer.Flush();

        }

    }

 

 

 

 

MySOAPExtensionServer.cs

SOAP Extension that will will expect a security token or string in incoming SOAP request.

 

using System;

using System.Web.Services;

using System.Web.Services.Protocols;

using System.IO;

using System.Net;

using System.Diagnostics;

 

    public class MySOAPExtensionServer : System.Web.Services.Protocols.SoapExtension

    {

        Stream oldStream;

        Stream newStream;

 

        public override object GetInitializer(LogicalMethodInfo methodInfo, SoapExtensionAttribute attribute)

        {

            return null;

        }

 

        public override object GetInitializer(Type WebServiceType)

        {

            return null;

        }

 

        public override void Initialize(object initializer)

        {

            return;

        }

 

        // Save the Stream representing the SOAP request or SOAP response into

        // a local memory buffer.

        public override Stream ChainStream(Stream stream)

        {

            oldStream = stream;

            newStream = new MemoryStream();

            return newStream;

        }

 

        public override void ProcessMessage(SoapMessage message)

        {

            switch (message.Stage)

            {

                case SoapMessageStage.BeforeSerialize:

                    break;

                case SoapMessageStage.AfterSerialize:

                    newStream.Position = 0;

                    Copy(newStream, oldStream);

                    break;

                case SoapMessageStage.BeforeDeserialize:

                    Copy(oldStream, newStream);

                    newStream.Position = 0;

                    break;

                case SoapMessageStage.AfterDeserialize:

                    if (message is SoapServerMessage)

                    {

                        if (!IsRequestValid(message))

                        {

                            LoggerSecurity.GetInstance().WriteLog("Invalid Service Call | Action = " + message.Action + " | Url = " + message.Url);

                            throw new SoapException("Invalid Service Call", SoapException.ClientFaultCode);

                        }

                    }

                    break;

            }

        }

 

        private bool IsRequestValid(SoapMessage message)

        {

            bool result = false;

            try

            {

                foreach (SoapHeader header in message.Headers)

                {

                    if (header is MyHeader)

                    {

                        MyHeader head = (MyHeader)header;

                        if (head.MyHeaderValue.Equals("MyValue"))

                            result = true;

                    }

                       

                       

                    else if (header is SoapUnknownHeader)

                    {

                        System.Xml.XmlElement elem = ((SoapUnknownHeader)header).Element;

                        if (elem.Name.Equals("MyHeader"))

                        {

                            System.Xml.XmlNode node = elem.SelectSingleNode("/");

                            if (node != null && node.InnerText.Equals("MyValue"))

                                result = true;

                        }

                    }

                }

            }

            catch (Exception ex)

            {

                LoggerSecurity.GetInstance().WriteLog(ex);

            }

            return result;

        }

 

        private void Copy(Stream from, Stream to)

        {

            TextReader reader = new StreamReader(from);

            TextWriter writer = new StreamWriter(to);

            writer.WriteLine(reader.ReadToEnd());

            writer.Flush();

        }

    }

 

 

In Client Web.Config before ending system.Web section add following

 

        <webServices>

              <protocols>

                    <remove name="HttpGet" />

                    <remove name="HttpPost" />

                    <remove name="HttpPostLocalhost" />

                    <remove name="Documentation" />

              </protocols>

              <soapExtensionTypes>

                    <add type="CustSoapExtension.MySOAPExtensionClient, CustSoapExtension" priority="1" group="High"/>

              </soapExtensionTypes>

        </webServices>

 

  </system.web>

 

 

 

In Server Web.Config before ending system.Web section add following

 

        <webServices>

              <protocols>

                    <remove name="HttpGet" />

                    <remove name="HttpPost" />

                    <remove name="HttpPostLocalhost" />

                    <remove name="Documentation" />

              </protocols>

              <soapExtensionTypes>

                    <add type="CustSoapExtension.MySOAPExtensionClient, CustSoapExtension" priority="1" group="High"/>

              </soapExtensionTypes>

        </webServices>

 

  </system.web>

 

 

Why these?

                    <remove name="HttpGet" />

                    <remove name="HttpPost" />

                    <remove name="HttpPostLocalhost" />

                    <remove name="Documentation" />

 

On production environment, if there is required only to consume webservices using only SOAP then don’t allow aceess to service using these protocoals. Only allow SOAP protocol.

 

 

Hope this sample code will help you to improve your security concern.

 

Comments (3)
Tue 24 Jun 2008


Configuration File Tampering

If Configuration files are not protected then you should use the file system access control list (ACL) to protect them.


System Registry Tampering

If registry entries are not protected then you should use the registry ACL to protect them.


Repudiation / Logging

Security exceptions should be logged for auditing purposes; therefore, you should define and implement logging and auditing strategies in the code. Push security exceptions–related information to the event log.


Assembly Tampering

To prevent assembly tampering, consider implementing Authenticode signatures for these assemblies.


Authentication and Authorization

You should consider various Internet, intranet, and extranet-based deployment for Web servers and database servers, and then implement appropriate authentication mechanisms.


Message Protection

You should implement transport-level security (secure socket layer [SSL]) to further strengthen the communication channel. You can also implement IPsec to secure communication channel between services and the database. To implement message-level security, use either WSE 3.0 or WCF to sign and encrypt messages. Choose appropriate certificates and encryption algorithms to enforce security without compromising business operations and performance.


HTTP Replay
Attacks

You can prevent these attacks by providing a secure end-to-end communication channel between server and client (for example, SSL). You should also uniquely authenticate each request (for example, use a timestamp and digital signature), by implementing message-level security. Implement IP lockout policies if required.


Denial of Service

You can prevent denial of service attacks by implementing strong authentication, authorization, and request validation mechanisms. Also, you should uniquely authenticate each request (for example, use a timestamp and digital signature) by implementing message-level security.


Repudiation

You can prevent repudiation attacks by implementing strong authentication, authorization, and request validation mechanisms. Also, you should implement the history and auditing feature for any database operations. You should not permanently delete the records from the database.


Dictionary Attack or Password Brute Force
Attack

You should try to prevent dictionary attacks or password brute force attacks. Implement strong password policies to prevent password hijacking. Implement a maximum retries policy, and disable the account if the number of attempts exceeds the maximum number. Also, implement an IP lockout policy, if required. Implement auditing and logging for service contracts / Web server / service host access.


Spoofing

You can prevent spoofing attacks by implementing strong authentication, authorization, and request validation mechanisms.


Database Security Access Controls

Use an account that has restricted permissions in the database. Ideally, you should grant execute permissions only to selected stored procedures. Consider using database role and application role database security concepts to access a different set of database objects. For example, consider using different sets of database roles and application roles for read-only operations and read-write operations.


Configuration Files Clear Text Secrets

To protect your connection strings, secret app settings, consider using DPAPI to encrypt them and store clear text secrets in a restricted registry. Use file ACLs to control access to configuration files.


Database Clear Text Secrets

The database contains secrets in clear text. For a production application, you should consider encrypting sensitive data.


Web Service Documentation Protocol

The Web.config file allows a malicious user to see the Web service documentation (wsdl file) by using documentation protocol. Using this information, the malicious user can get information about all data contracts and service contract details. The malicious user can then use the details to launch brute force attacks or false request attacks. You should configure the Web.config file to disable the documentation protocol.


Debug Attribute

The host program configuration file allows debugging. The Web.config file describes the debug = true attribute, which can allow the malicious user to debug the service implementation. This opens extra surface area, which allows a malicious user to explore injection threats. To prevent this type of attack, configure debug = false in the Web.config file.


CustomErrors Mode Attribute

The host program configuration file allows debugging. The Web.config file describes the CustomErrors Mode = off attribute, which can allow the malicious user to see the complete debug information in case of errors or exceptions. A malicious user can get the call stack information, which can launch injection or code malfunction attacks. To prevent this type of attack, configure CustomErrors Mode = on and make sure that the defaultUrl is appropriately configured in the Web.config file.

 

PersistSecurityInfo Attribute

The database connection string in the Web.config file does not contain a definition for the PersistSecurityInfo attribute. This attribute should be set to false. When set to false, sensitive information, such as the password, is not returned as part of the connection if the connection is open or has ever been in an open state. Resetting the connection string resets all connection string values, including the password. Set the PersistSecurityInfo attribute to false in the connection string.


SqlClientPermission Attribute

The database access assembly does not define the code access security attribute SqlClientPermission.

The CustomerRepository assembly should request minimum security permissions for SqlClientPermission.


Unrestricted Base Classes

When developing classes that will be deployed to a production environment, you should consider using sealed attributes for classes and methods.

 

Comments (1)