Commonly asked Application Security interview questions? Part 1

Written By Syed Huda
appsec-interview.jpg

About 2-3 years back, I had the urge to make a shift to a full stack Application Security role. In my head, I had this idea that transitioning to a singular and more specialised security section like Application Security would open wider doors for progression and so I started to look for Application Security roles. During the process of preparing for interviews and also appearing for interviews (places, where I took interviews, will be left unnamed) I drafted a list of commonly asked ‘technical’ questions and some of their associated answers and references while to aid my preparations. Whilst most of these organisations asked about scenario and behaviour based questions based on the STAR methodology as well, I will leave that preparation for another blog post and continue to discuss commonly asked ‘technical’ questions/answers I prepared during my hunt for an Application Security role.

Before it gets boring, let’s dive into the real content. I’ve listed my list of questions, their associated answers (which I think are correct and up to date to my knowledge) and some reference links which I think will help if the answers need to be elaborated.

Which architecture is more secure? 2 tier or 3 tier?

Let's say you have a user table in your database that contains hashed passwords. In order to validate a user's login, you need to query the table for the hash that applies to the user in question. Now consider how the web app in the DMZ handles user password validation:

  • In the 2-tier solution, the web app connects directly to the DB and queries the table.

  • In the 3-tier solution, the web app sends the user id and password to the application layer and get's a yes/no answer.

Now consider what that means if the web app is compromised. In the 2-tier solution, it may be possible to modify the query or create a new query that retrieves the entire user table with all the hashed passwords. In the 3-tier solution, you have only the specific capabilities provided by the application layer and (ignoring flaws in that layer) you lack access to the underlying tables. Effectively, the app layer allows for controlled white-listing of what the web app can do with regard to data access by removing direct access to the data store.

Reference:

Explain the SSL Handshake

These are the essential principles to grasp for understanding how SSL/TLS works:

  • Secure communication begins with a TLS handshake, in which the two communicating parties open a secure connection and exchange the public key

  • During the TLS handshake, the two parties generate session keys, and the session keys encrypt and decrypt all communications after the TLS handshake

  • Different session keys are used to encrypt communications in each new session

  • TLS ensures that the party on the server-side, or the website the user is interacting with, is actually who they claim to be

  • TLS also ensures that data has not been altered, since a message authentication code (MAC) is included with transmissions

With TLS, both HTTP data that users send to a website (by clicking, filling out forms, etc.) and the HTTP data that websites send to users is encrypted. Encrypted data has to be decrypted by the recipient using a key.

The 'client hello' message: The client initiates the handshake by sending a "hello" message to the server. The message will include which TLS version the client supports, the cipher suites supported, and a string of random bytes known as the "client random."

  1. The 'server hello' message: In reply to the client hello message, the server sends a message containing the server's SSL certificate, the server's chosen cipher suite, and the "server random," another random string of bytes that's generated by the server.

  2. Authentication: The client verifies the server's SSL certificate with the certificate authority that issued it. This confirms that the server is who it says it is, and that the client is interacting with the actual owner of the domain.

  3. The premaster secret: The client sends one more random string of bytes, the "premaster secret." The premaster secret is encrypted with the public key and can only be decrypted with the private key by the server. (The client gets the public key from the server's SSL certificate.)

  4. The private key used: The server decrypts the premaster secret.

  5. Session keys created: Both client and server generate session keys from the client random, the server random, and the premaster secret. They should arrive at the same results.

  6. The client is ready: The client sends a "finished" message that is encrypted with a session key.

  7. The server is ready: The server sends a "finished" message encrypted with a session key.

  8. Secure symmetric encryption achieved: The handshake is completed, and communication continues using the session keys.

Reference:

Explain CORS and Same Origin Policy

Invocations of the XMLHttpRequest or Fetch APIs, web fonts and CSS style sheets all use CORS. Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell browsers to give a web application running at one origin, access to selected resources from a different origin. A web application executes a cross-origin HTTP request when it requests a resource that has a different origin (domain, protocol, or port) from its own. 

Access-Control-Allow-Origin: **<https://foo.example>**
Access-Control-Allow-Origin: *** (Wild card)**
Access-Control-Allow-Origin: <http://foo.example>
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400

Reference:

When Is Same-Origin Policy Applied

Origin checks are applied by the browser in every case of potential interaction between elements from different origins. This includes, but is not limited to:

  • JavaScript code and the Document Object Model (DOM), for example, a page cannot access the content of its iframe unless they are of the same origin

  • Cookies, for example, your session cookie for a particular site cannot be sent to a page with a different origin. However, in the case of cookies, schema and port are not evaluated, only the domain/subdomain

  • AJAX calls (XmlHTTPRequest).

Same-Origin Policy on its own increases security but is not enough to prevent all Cross-Site Request Forgery (CSRF) attacks, which basically are an attempt to take advantage of different origins. That is why anti-CSRF tokens should still be used as an additional form of protection. SOP is also completely useless as a method of protection against Cross-site Scripting (XSS) because it would have to limit loading of scripts from different sites and that would completely hinder the functionality of web applications.

References:

What is non Repudiation and how does it apply to IT security?

Non-repudiation is the assurance that someone cannot deny the validity of something. Non-repudiation is a legal concept that is widely used in information security and refers to a service, which provides proof of the origin of data and the integrity of the data.

How would you implement a secure login field on a high traffic website where performance is a consideration?

Make a separate login page that can only be accessed with https and (of course) submits using https. Always enforce https on the homepage and include the login form there. This makes it more convenient to log in and more secure because users are more likely to bookmark the https homepage than a separate login page. Some examples include:

  • Open ID

  • Facebook connect

What is the best way to prevent XSS attacks?

Preventing cross-site scripting is trivial in some cases but can be much harder depending on the complexity of the application and the ways it handles user-controllable data. In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:

  • Filter input on arrival. At the point where user input is received, filter as strictly as possible based on what is expected or valid input.

  • Encode data on output. At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.

  • Use appropriate response headers. To prevent XSS in HTTP responses that aren't intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.

  • Content Security Policy. As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.

What are RFCs:

For better or worse, Requests for Comments (RFCs) are how we specify many protocols on the Internet. These documents are alternatively treated as holy texts by developers who parse them for hidden meanings, then shunned as irrelevant because they can’t be understood. This often leads to frustration and – more significantly – interoperability and security issues. However, with some insight into how they’re constructed and published, it’s a bit easier to understand what you’re looking at.

Can you describe rainbow tables?

A rainbow table is a precomputed table for reversing cryptographic hash functions, usually for cracking password hashes. Tables are usually used in recovering a password (or credit card numbers, etc.) up to a certain length consisting of a limited set of characters.

What are cryptographic hash functions?

Cryptographic Hash Functions are used to achieve a number of Security goals like Message Authentication, Message Integrity, and are also used to implement Digital Signatures (Non-repudiation), and Entity Authentication.

What is a Block Cipher?

In cryptography, a block cipher is a deterministic algorithm operating on fixed-length groups of bits, called blocks. It uses an unvarying transformation, that is, it uses a symmetric key.

How long would it take to break RSA?

It would take a classical computer around 300 trillion years to break a RSA-2048 bit encryption key.

What is public key cryptography?

Review of Public Key Cryptography, and A Specific Example: PGP . Anchor link. ... Public key encryption actually just encrypts a symmetric key, which is then used to decrypt the actual message. PGP is an example of a protocol that uses both symmetric cryptography and public key cryptography (asymmetric).

What is OAuth and how does it work?

OAuth doesn't share password data but instead uses authorization tokens to prove an identity between consumers and service providers. OAuth is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password.

What are the 3 types of security controls:

  • Security

  • Operational Security

  • Physical Security Controls

Does SOP mitigate CSRF attacks?

Same-Origin Policy on its own increases security but is not enough to prevent all Cross-Site Request Forgery (CSRF) attacks, which basically are an attempt to take advantage of different origins. That is why anti-CSRF tokens should still be used as an additional form of protection. SOP is also completely useless as a method of protection against Cross-site Scripting (XSS) because it would have to limit loading of scripts from different sites and that would completely hinder the functionality of web applications.

Cross-domain requests and form submissions are still permitted but reading data from another origin is not permitted. This means that if you are performing a CSRF attack on a vulnerable site which results in some server side state change (e.g. user creation, document deletion etc), the attack will be successful but you would not be able to read the response.

In short SOP only prevents reading data which was served from a different origin. It does not cover cross-domain form submissions which are used to carry out a CSRF attack.

References:

How do you Prevent CSRF?

In short, the following principles should be followed to defend against CSRF:

Explain CRL? Certificate Revocation List:

As SSL Certificates themselves are signed by Certificate Authorities, a degree of "domain validation" is carried out - the Certificate Authority makes sure they are only validating a certificate which is owned by someone who has the ability to make changes to the website. This provides a degree of assurance that certificates aren't being issued to attackers who can then seem legitimate when intercepting web traffic. In the event a certificate ends up in the wrong hands, a Certificate Revocation List can be used to retract the certificate.

Explain SSL Stripping:

Usually wireless attack Like KRACK where the attacker gets the victim to connect to a hotspot and intercept their encrypted communication.

In order to “strip” the SSL, an attacker intervenes in the redirection of the HTTP to the secure HTTPS protocol and intercepts a request from the user to the server. The attacker will then continue to establish an HTTPS connection between himself and the server, and an unsecured HTTP connection with the user, acting as a “bridge” between them.

References:

How does file compression work?

  • Huffman coding is quite complicated, and we won’t be going into detail on that one here. Primarily, it uses some fancy math to assign shorter binary codes to individual letters, shrinking file sizes in the process. If you want to learn more about it, check out this article on how the code works, or this explainer by Computerphile.

  • LZ77, on the other hand, is relatively simple and is what we’ll be talking about here. It seeks to remove duplicate words and replace them with a smaller “key” that represents the word.

References:

Which method is secure? Compress First and then Encrypt the data or Encrypt First then Compress?

There is no difference in the security provided, but because of the way compression algorithms work, you are probably going to get better compression if you compress first then encrypt. Compression algorithms exploit statistical redundancies (such as those that exist in natural language or in many file formats) in the data which should be eliminated when you encrypt it, therefore an encrypted message shouldn't be able to be compressed all that well.

References:

You have found a vulnerability in a product/infrastructure, how will you investigate if this was not exploited already by an attacker?

  1. Close off public access wherever possible

  2. Rely on statistics-based detection (machine learning)

  3. Engage in preventative security practices

  4. Evaluate and quarantine

  5. Have an incident response team ready

  6. Lock down systems

  7. Educate Employees

  8. Maintenance mode and patching

What is SPF, DKIM and DMARC?

  • SPF is an acronym for “Sender Policy Framework”. As with all three checks, SPF is a DNS TXT record that specifies which IP addresses and/or servers are allowed to send email “from” that particular domain. It’s essentially like the return address that’s placed on a letter or postcard that lets the recipient know who sent the communication.

  • DKIM is an acronym for “DomainKeys Identified Mail”. It’s also known as “email signing”. Just like an SPF record, DKIM is a TXT record that’s added to a domain’s DNS. And if SPF is like a return address on a letter, DKIM is like sending that letter via Certified Mail as it further builds trust between the sending server and receiving server.

  • DMARC DMARC is an acronym for “Domain-based Message Authentication, Reporting and Conformance”. It’s an email authentication, policy and reporting protocol that’s actually built around both SPF and DKIM. It has three basic purposes:

  1. It verifies that a sender’s email messages are protected by both SPF and DKIM,

  2. It tells the receiving mail server what to do if neither of those authentication methods passes, and

  3. It provides a way for the receiving server to report back to the sender about messages that pass and/or fail the DMARC evaluation.

References:

What are the security implications in DNS?

Registrar hijacking

Domain names are commercially bought and sold through a registrar company and this may make them vulnerable to fraud. If a hacker compromises the DNS commercial account you hold with your registrar, they can take control of the domain, transfer ownership and point it to servers under their control. This is done by breaking account passwords or socially engineering the registrar’s support personnel.

Typosquatting

The next best thing to registrar hijacking is typosquatting. If you can’t break it, fake it. Typosquatting is the practice of registering a fake domain name that is almost identical to the real (target) business domain name. Hackers do this to misdirect web traffic and to set up a wide variety of phishing attacks.

Cache poisoning

DNS data is used to send mails and to find websites across the internet and is cached on servers to reduce loads and improve performance. However, the DNS data cached on these servers may be vulnerable to “poisoning” attacks.

Is the DNS service communication encrypted?

Normal DNS queries and responses are not encrypted. However, there are many technologies hoping to change that; some of these are proprietary solutions, some are emerging standards. We will discuss each briefly in this article.

  • DNS Curve

  • DNS Crypt

  • VPN

  • IPSEC A

  • DNS Over TCP

How does ssh authentication work?

Authentication using SSH key pairs begins after the symmetric encryption has been established as described in the last section. The procedure happens like this:

  1. The client begins by sending an ID for the key pair it would like to authenticate with to the server.

  2. The server check’s the authorized_keys the file of the account that the client is attempting to log into for the key ID.

  3. If a public key with a matching ID is found in the file, the server generates a random number and uses the public key to encrypt the number.

  4. The server sends the client this encrypted message.

  5. If the client actually has the associated private key, it will be able to decrypt the message using that key, revealing the original number.

  6. The client combines the decrypted number with the shared session key that is being used to encrypt the communication and calculates the MD5 hash of this value.

  7. The client then sends this MD5 hash back to the server as an answer to the encrypted number message.

  8. The server uses the same shared session key and the original number that it sent to the client to calculate the MD5 value on its own. It compares its own calculation to the one that the client sent back. If these two values match, it proves that the client was in possession of the private key and the client is authenticated.

References:

How would you create and implement an SSL certificate?

Any certificate in between your certificate and the root certificate is called a chain or intermediate certificate. These must be installed to the web server with the primary certificate for your web site so that user's browers can link your certificate to a trusted authority. Most certificate authorities use intermediate certificates for security purposes and most web servers and devices support them. To find out more about Intermediate certificates and why most providers require them for SSL Certificate installation, see Extinction of Unchained SSL Certificates.

References:

In which phase of SDLC should security be integrated?

A better practice is to integrate security activities across the SDLC–from the planning phase to release. This helps discover (and fix!) defects close to the time they're introduced.

Explain encryption in Wifi network communication.

Wireless encryption secures your wireless network with an authentication protocol. It requires a password or network key when a user or device tries to connect. ... You can locate the encryption key when you log into the router setup page if you have created your own encryption key.

How is the state of a request saved in HTTP?

HTTP is a stateless protocol. That is, the server does not hold any information on previous requests sent by the client. Client-side cookies were introduced by Netscape to maintain state, by storing client-specific information on the client's machine and later retrieved to obtain the state information.

What is salt in cryptography?

In cryptography, a salt is random data that is used as an additional input to a one-way function that hashes data, a password or passphrase. Salts are used to safeguarding passwords in storage.

What is Double-Submit Cookie?

These are used to prevent CSRF attacks. Cookies are sent automatically with every request, regardless of whether the request was initiated by the original site or by a third-party site. That’s why a cookie alone does not suffice as every request will contain it.

But by having the token also in the request itself, an attacking site cannot generate valid requests any more as they can’t get a hold on the user’s token.

What is the Preflight request?

A CORS preflight request is a CORS request that checks to see if the CORS protocol is understood and a server is aware using specific methods and headers.

For example, a client might be asking a server if it would allow a [DELETE](<https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/DELETE>) request, before sending a DELETE request, by using a preflight request: It is an [OPTIONS](<https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OPTIONS>) request, using three HTTP request headers: [Access-Control-Request-Method](<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Request-Method>), [Access-Control-Request-Headers](<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Request-Headers>), and the [Origin](<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin>) header.

A preflight request is automatically issued by a browser and in normal cases, front-end developers don't need to craft such requests themselves. It appears when the request is qualified as "to be preflighted" and omitted for simple requests.

For example, a client might be asking a server if it would allow a [DELETE](<https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/DELETE>) request, before sending a DELETE request, by using a preflight request:

OPTIONS /resource/foo 
Access-Control-Request-Method: DELETE 
Access-Control-Request-Headers: origin, x-requested-with
Origin: <https://foo.bar.org>

If the server allows it, then it will respond to the preflight request with an Access-Control-Allow-Methods response header, which lists DELETE:

HTTP/1.1 204 No Content
Connection: keep-alive
Access-Control-Allow-Origin: <https://foo.bar.org>
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Max-Age: 86400

The preflight response can be optionally cached for the requests created in the same URL using Access-Control-Max-Age header like in the above example.

References:

What are Certificate Transparency Logs?

Certificate Transparency logs. Every Certificate Transparency log is a record of all publicly trusted digital certificates. Those certificates contain information about the public key, the subject and information about the issuer.

Your favourite burp suite extensions?

What is your favourite vulnerability and why?

Input validation and Lack of Anti automation feature to check email flooding through burp collaborator by sending flood request is top of the list for checking for vulnerabilities in a web application, API or web service.

Talk about any latest vulnerability or breach you learnt about?

SigRED: CVE-2020-1350 lets a malefactor force DNS servers running Windows Server to execute malicious code remotely. In other words, vulnerability belongs to the RCE class. To exploit CVE-2020-1350, one just has to send a specially generated request to the DNS server. The Check Point research team discovered that the DNS SIG response parser in the Microsoft DNS server code appears to be a great place to target exploits, and once a Microsoft DNS server is compromised, it can be turned into a DNS client, thus making this a very wormable bug. You will really want to pay attention to SIG requests for the foreseeable future. Check Point further notes that the exploit is viable via both TCP and UDP delivery paths for DNS requests and that it is possible to smuggle DNS requests into HTTP requests, meaning phishing attacks could be further weaponized beyond traditional credential stealing to Microsoft DNS server compromise attempts.

Top people, you follow for security research?

  • Dave Kennedy

  • Rapid 7

  • Fireeye

  • MooseSec

  • Mr Reb00t

  • Adam Caudill

  • Digininja

  • Dark Reading

  • Zero-Day Security

  • Krebs on Security

  • Albatchy blog

  • NotSoSecure

What is HSTS?

The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP.

The Strict-Transport-Security header is ignored by the browser when your site is accessed using HTTP; this is because an attacker may intercept HTTP connections and inject the header or remove it. When your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honour the Strict-Transport-Security header.

Directives

  • max-age=<expire-time> The time, in seconds, that the browser should remember that a site is only to be accessed using HTTPS.

  • includeSubDomains Optional If this optional parameter is specified, this rule applies to all of the site's subdomains as well.

  • preload OptionalSee Preloading Strict Transport Security for details. Not part of the specification.

References:

If you have API calls which need to fetch credentials, what will be the secure way to store secrets and making them available for API calls?

Access SSM or SecretsManager at runtime and use caching. Store your credentials safely encrypted on Systems Manager Parameter Store or on Secrets Manager (which allows also automatic rotation) and access them at runtime.

Then configure your serverless YAML granting access to your lambda via IAMRole Policies:

iamRoleStatements: - Effect: Allow Action: - ssm:GetParameter Resource:"arn:aws:ssm:YOUR_REGION:YOUR_ACCOUNT_ID:parameter/YOUR_PARAMETER"

You can set this permission with growing levels of granularity:

"arn:aws:ssm:*:*:parameter/*" "arn:aws:ssm:YOUR_REGION:YOUR_ACCOUNT_ID:parameter/*" "arn:aws:ssm:YOUR_REGION:YOUR_ACCOUNT_ID:parameter/YOUR_PARAMETER-*" "arn:aws:ssm:YOUR_REGION:YOUR_ACCOUNT_ID:parameter/YOUR_PARAMETER-SOME_MORE_SPECIFIC"

The code above is specifying directly your ARN / Region / Account — if you want to be more flexible you can set up the permission to grab those value automatically.

References:

XXE Attacks and their Mitigation if they must be used for business?

  • Referred in OWASP top 10 as Insecure Deserialization or IDOR

  • Burp supports XXE detection, can use collaborator payload in the ENTITY header of the XML

<!DOCTYPE Response [  
 <!ENTITY message SYSTEM "f**ile:///etc/passwd**" >
]> 
<Response>&message;</Response>

  • An XML External Entity vulnerability occurs when the service that parses (or in simpler words, reads and processes) the XML messages sent by the client, accepts an external definition of the XML message itself. This message definition, known as external DTD, allows for extraordinary flexibility so that the sender and receiver can agree on new message formats during runtime. External DTD is designed to be used when both parties are trusted.

  • External defences like Web Application Firewalls (WAFs) struggle to stop XML External Entity attacks. Multiple levels of atypical encodings, such as UTF-16 and UTF-32, plus encryption dramatically hamper the WAF’s visibility of traffic.

Mitigation:

  • In order to avoid an XML External Entity vulnerability, teams must configure their XML parsers so that they don’t accept custom document definitions (DTDs). There are very few instances in which an application truly requires a custom DTD, so the functionality trade-off is small. However, the difficulty lies in the fact that each parser, in each programming language, has its own way of setting this configuration parameter. So, if one project includes multiple parses, each parser will have to be configured properly and manually.

  • Avoid by design: choose APIs that use other formats such as JSON or YAML

  • Watch out for dependencies: remember, third party code might be introducing XXE vulnerabilities

  • Automate protection: eliminate the manual configuration process and ensure protection by relying on automatic security checkpoints based on instrumentation, such as Hdiv Protection

  • Proper configuration: if it’s not possible to remove external DTDs by design or automate protection, then configure all your XML parsers to whitelist only trusted external DTDs

  • Containment: properly configure the execution context of the server to limit external code execution or server file system browsing

References:

Syed Huda
Previous

Commonly asked Application Security interview questions - Part 2
Next

Certified Red Team Professional - Review