Your SlideShare is downloading. ×
Overview of Network Application Attacks
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Overview of Network Application Attacks

276
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
276
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. As SOA has exploded on the scene many managers and business executives rushed to exploit the  benefits that come with SOA as implemented in the form of Web Services.  The financial services  companies who would like to make sensitive client information available to sales people in the field;  doctors and hospitals who would like to share patient information to facilitate better communication and  patient diagnosis.  SOA, as an architecture, has enabled legacy systems that were developed at great time,  talent, and financial expense to no longer be confined behind the firewalls of companies and organizations  that have sensitive information that must be protected from hackers, industrial spies.  By providing a  common interface between application located on disparate systems, code redesign is minimized through  the codified standardization of communications; it matters not much what language or platform one  element of a web service is implemented in or on, as long as the results of a single process is consumable  by another under the standard methods of communication. SOA as implemented in web services is based on the Message Oriented Model (affectionately  called MOM); under this scheme, messages act as the glue that holds the disparate parts of the architecture  together.   In web services the disparate parts “know” very little about each other as compared to  architectures such as might employ method call, in which each active element must know the address and,  more importantly, the interface of the target agent that would be processing the request.  [Also the  messages where often in binary and sometimes even in a proprietary format that may have been built off of  an exiting standard.]   Because of anonymity among components, all a service may have is an address and a  broad interface description when forming the message.  This message is often built on top of the existing  XML (Extensible Markup Language) standard, which is a 16­bit standard for information exchange over  the Internet.  SOAP (Service Oriented Architecture Protocol) is also the main format that the message takes  within this environment.  All of these technologies are based on older technologies that were implemented  for the Internet since the 1980s and 1990s.  These technologies enabled the efficient transmission of  information across many different hardware and system types and boundaries because they use the lowest  common denominator, which is 16­bit UNICODE text to communicate. [OASIS, 2003; Brose, 2003] Due to the inherent weaknesses in the routing of XML based messages Enterprise Service Bus was developed as a messaging architecture which is used in combination with Web services to provide: • “ Service-oriented architecturesin which applications communicate through reusable services with well-defined, explicit interfaces. Service- oriented interactions leverage underlying messaging and event communication models.” • “Message-driven architecturesin which applications send messages through the ESB to receiving applications.” • “Event-driven architecturesin which applications generate and consume messages independently of one another.”[ Martin Keen, 2004] “And most of the recently announced XML Web Services security specifications, such as WS­Security,  SAML, and XML Encryption incorporating schema validation, XML/SOAP encryption, and XML  signaturing, require extensive XML processing. Because they are all, like XML, interpretive in nature to  maintain platform independence, they slow down a system's ability to process messages where any degree  of security is required, unless a considerable amount of brute force computing resources are used.”  This  was the attitude of security experts in the filed. [WebServices.org, 2004] XML by W3C standards is not encrypted so to make the life blood of the SOA technology secure, web  security pioneers developed standards such as: Digital Signatures The use of a public and private key system that is used to encrypted messages  with a private key and only decrypted with the public key that is made available  by the author of the keys. A certificate authority certifies the keys.  Used to  encrypt each message sent over system. SSL/TLS A dual layered system by which data is transmitted securely between two  1
  • 2. Digital Signatures The use of a public and private key system that is used to encrypted messages  with a private key and only decrypted with the public key that is made available  by the author of the keys. A certificate authority certifies the keys.  Used to  encrypt each message sent over system. parties.  The parties will decide on a cryptography algorithm and a private key  that will be used to encrypt the data when the initial handshaking occurs. This  protocol sits top of transport protocols like TCP/IP. HTTPS A protocol that is a combination of using SSL/TLS and HTTP to encrypt  messages between a web browser and the web server. PK I, II An implementation of the Digital signatures standard. WSA ­ Policy Policy for Web services consists of facts, or assertions, and rules that apply to a  particular Web service.  .... Policy may be used by the over­arching concerns:  security, quality of service, and management; as well as higher layers of the  description stack.2 The standardization of security practices across domains, it is sometimes suggested, is required to  promote a truly “open market.” How necessary this may be may be debated, although, clearly steam­lining  commercial processes requires that all parties adhere to a set of practices. A notable historical allegory can  be summoned by recollecting that roughly 15 years ago the bevy of independent e­mail providers (CCMail,  X.400, UUCP, etc.) each maintained their own protocols and security systems.  The effect was a massive  complication at the edges of the disparate systems when the messages needed to be transferred to a  different system [Djajadinata, 2004].  Some forms of data exchange have no small amount of risk should  the data be intercepted and decrypted. A financial trading application, for example presents a uniquely  difficult exchange pattern: results must be visible in (at least) soft real­time. Given the noted diversity of  requirements that are applied to the SOA model, the issue of whether a common standard is feasible across  the commercial network industry in toto. [Van der Togt, 2003] This has caused a hodge­podge security model where one weak security algorithm or vulnerable  intermediate agent with weakened security can expose the message to eavesdropping or worse.  The chain  is diverse at many points with no common standard or over site of intermediate agents.  In traditional  systems, one organization had supervision over the communication framework and hardware or has a  standard end­to­end encryption, but with SOA there are expanded requirements. A point­to­point  encryption mechanism, as provided for SSL or S/MIME is not sufficient. A web service message may  involve pass through a bevy of devices and gateways. SSL ensures the security transferring from any single  given point to another, but not a totality end to end. Therefore, when it comes to SOA for security sensitive  information, an entire network is vulnerable to the “Weakest Link” effect.     It is unreasonable and non­extensible to plan on trying to hash together a more elaborate security  system out of existing point­to­point technologies. The obvious solution in a multiparty transaction, say,  where a user purchases a product online, passing the credit card or bank number to the bank via the  merchant’s web site, is to selectively encrypt particular segments of the message. The merchant should not  have direct access to the financial information of the user, and the bank need not know the specifics of the  purchase, hence only relevant information should be visible to the correct parties. This is selective  encryption whereby the portions of the message are encrypted using a cipher that only the intended  recipient has the key to decrypt; the same XML encoded message may then be passed to all involved  parties with a measure of security. There is then, that SSL, SOAP, or other such standards do not natively provide for transport layer  end­to­end security. In order for the desired end­to­end security, application level security must be utilized.  Below is a list of some of the attacks that have been perpetrated against Web Service systems, therefore  necessitating the need for improved security standards. 2
  • 3. Overview of Network Application Attacks Message Alteration Modifying any part of a message from that sent from the original sender Attachment Alteration Modifying any part of the message attachment Confidentiality Attacks Viewing of message data by non­intended party. Falsified Message/ Spoofing Third party uses information from a two party conversation to send falsified  messages to one or both of the parties. Man in the Middle Similar to Falsified Messages for all intents and purposes. XML Encryption – Data Confidentiality XML had been adopted as a standard for web services for one simple reason: it allowed for  unstructured data to be comprehended via a map of tags to schema. This movement towards self­describing  data is beneficial as a method for standardizing, for the simple reason that extensibility minimizes the  troublesome cost of upgrading when there is a change to industry standards.  XML Encryption has been laid out to provide the adequate clarity of document form as befits  XML. This is achieved by selectively encoding only segments of the XML messages under a specified tag:  EncryptedData such as such: <Item>          <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#">             <CipherData>               <CipherValue>BNjivf7gTOhHmcfZ . . . .CipherValue>             </CipherData>          </EncryptedData> </Item> [Siddiqui, 2003] XML Security – Integrity and Authentication Beyond encrypting the data that it might not be (easily) discovered, attacks to such distributed  systems must also be checked that they are valid regarding origin and intent. Replay attacks maybe  initiated to confound the system of derive information. Similarly, parts of messages may be rewritten while  in transit, if merely as a nuisance. The message needs to be protected from intrusion and the origin needs to  be authenticated as the identity the message claims it has originated from. In both cases, some form of third  party verifying service is required.  XML Digital Signatures are employed to validate integrity. By including this data in the encrypted  data, even individual segment may be checked for intrusion. The receiving party may then check the  signature by pulling from verification a third party. <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> ... </ds:SignedInfo> <ds:SignatureValue> ... </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse: Reference URI=”#ABCDEFG” /> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> For the matter of the identity verification, some third party is required as alluded above. There are  three forms of Security Token that may be implemented: Unsigned security tokens • Username Signed security tokens (binary) 3
  • 4. • X.509 certificates • Kerberos tickets XML security tokens • Any XML token, such as SAML The first provides some minimal protection, but is the easiest to falsify by stripping or otherwise gleaning  the username. Signed security tokens will carry the token generated by a third party, which then may be  crosschecked. X.509 or Kerberos are frequently checked by pulling from the token service, but as with  XML SAML tokens may be self verifying if such a pre­described method if available. SAML (Security  Assertions Markup Language) is an XML based markup language that allows for single sign on style  onetime validation via an identity provider. In this mode if self­validating token use, the third party need  only be involved on a single or minimal basis, essentially acting as a party that “introduces” the two (or  more) essential parties to each other. [IBM, 2002, OASIS, 2003] In conclusion, after scrutinizing the security model of the SOA messaging model with regards to security  as implemented in Web Services, we have come to the opinion that only as of late has XML become a  viable security alternative for the development of high security application even though there are still  issues with performance. With the passage of the WSS security ratified as the OASIS standards in 2004,  one now has the tools necessary to provide secure data over the Internet in the form of Web Services,  though processing of WSA Security compliant XML will still incur performance penalties as stated earlier.  Will the new standards solve all of the problems?  I would venture to say no, but it does take us in the right  direction. References Brose, Gerald (2003).  Securing Web Services with SOAP Security Proxies. Procs. ICWS 03, International Conference on Web Services 2003, Las Vegas, USA. pp. 231­234. http://www.jacorb.org/~brose/papers/ Djajadinata, Ray (2002). Yes, you can secure your Web services documents. JavaWorld.com. http://www.javaworld.com/javaworld/jw­08­2002/jw­0823­securexml­p2.html IBM (2002). Specification: Web Services Security (WS­Security), Version 1.0 05, April.  http://www­106.ibm.com/developerworks/library/ws­secure/ OASIS (2003). Assertions and protocol for the OASIS Security Assertion Markup Language. Committee  Specification. Siddiqui, Bilal (2005). Web Services Security. XML.com. http://webservices.xml.com/lpt/a/ws/2003/03/04/security.html Van der Togt, Ted and William Strabbing (2003). Standardization and Security in Message Exchange.  Metering International. Issue 3. p. 44.  http://www.metering.com/archive/033/46_1.htm Mark Davis, Bret Hartman, Chris Kaler, Anthony Nadalin, and Jerry Schwarz (2004) WS-I Security Scenarios. Vol. 15 Hallam­Baker, Phillip (2004). XML Key Management Services http://www.w3.org/2001/07/xkms­ws/positions/VeriSign.htm Youd, David (1996). What is a Digital Signature? http://www.youdzone.com/signature.html Allen Brown, Barbara Fox, Satoshi Hada, Brian LaMacchia, and Hiroshi Maruyama (2001) 4
  • 5. SOAP Security Extensions: Digital Signature http://www.w3.org/TR/2001/NOTE­SOAP­dsig­20010206/#motivation Martin Keen, Amit Acharya, Susan Bishop, Alan Hopkins, Sven Milinski, Chris Nott, Rick Robinson, Jonathan Adams, and Paul Verschueren (2004) Patterns: Implementing an SOA Using an Enterprise Service Bus p. 76 WebServices.org, (2004) Web Services Security (WSS) Officially Ratified as OASIS Standard http://www.webservices.org/index.php/ws/content/view/full/3736 5
  • 6. SOAP Security Extensions: Digital Signature http://www.w3.org/TR/2001/NOTE­SOAP­dsig­20010206/#motivation Martin Keen, Amit Acharya, Susan Bishop, Alan Hopkins, Sven Milinski, Chris Nott, Rick Robinson, Jonathan Adams, and Paul Verschueren (2004) Patterns: Implementing an SOA Using an Enterprise Service Bus p. 76 WebServices.org, (2004) Web Services Security (WSS) Officially Ratified as OASIS Standard http://www.webservices.org/index.php/ws/content/view/full/3736 5