Philip Kulp

Author
+ Follow
since Mar 12, 2022
Merit badge: grant badges
Biography
Cybersecurity expert who loves to code. Java, Python, JS
For More
Washington, DC
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Philip Kulp

Congratulations. Thanks for all the interesting questions.
2 years ago
I'm not sure if there was a question, but to address Multi-Factor Authentication (MFA)...yes it helps but still is not perfect. Criminals can still phish your MFA by pretending to be the website, sending the token request in the background, and then presenting the MFA question. You receive the response and then input the token into the form, which the criminal then proxies on to the real website. Another example is if you have MFA enabled on Outlook with the app on your phone. A criminal can try to reset the password, the token request gets sent to your phone, and if you aren't paying attention, you can accept the request accidentally. Or, criminals are now spamming the requests till a user get annoyed, thinks there is a problem, and just hits accept to make it stop.
2 years ago
Cookies store data on the client (user's browser) for access at a later time or to maintain some session information. Cookies can be manipulated by the user or stolen by attackers so they are not considered safe. Sensitive information should be stored as session information on the server side.
2 years ago
As other have send, it depends on the sensitivity of the data. Some enterprises have a proxy which can decode TLS traffic (for security and monitoring) which could expose sensitive data. Depending on the final point of processing, the data may still traverse a portion of the network unencrypted, so understand your data end-to-end. For example, many use a front end proxy AWS ELB, Nginx, etc. which then transmit the data to a back-end application server which does the "real" execution. Some people configure the TLS on the load balancer and then it communicates over non-encrypted channel to the application, php engine, etc. Attacking this data would require an insider with access to this final communication channel (which is already really bad). This is why you need to understand your architecture, sensitivity of data, and risk acceptance profile to determine which controls are required for your organization
2 years ago
Malware, anti-virus, and the next generation Endpoint Detection and Response (EDR) agents will detect could detect these types of attacks by blocking access to know bad URLs.
You can harden Cookies on your site with headers that protect them from being posted to other sites outside of your domain.
For example, adding Domain to the Cookie sent to your users keep it on your domain:
Domain=mydomain.com

You can also protect Cookies from being stolen over unprotected network or other ways with other flags such as: Secure, HttpOnly, and SameSite.
HttpOnly flag and other can help against Cross-Site Scripting (XSS) attacks that try to steal Cookie or session.
2 years ago
JS is run in the browser, so from that perspective there aren't external sites. The more important idea is to sanitize all input AND output that is received from a user or other "external" source. You sanitize the input so that you avoid using tainted data which could lead to other injection problems to SQL, Java deserialization, JSON deserialization, and more. XSS is about your site repeating the malicious code, so you filter all output to keep your site from being the enabler against the victims. Check out the OWASP Encoder project and look at the How to Use tab. They have filtering mechanism for just about all situations, even if you are using JSP.
https://owasp.org/www-project-java-encoder/
2 years ago
You do not need a security background to understand the concepts. We could not cover every possible security topic obviously, but tried to give a wide range of examples to learn from such as unstable handling of numeric data, insecure webapp calls, injection attacks, and more. Specific frameworks were not addressed to avoid excluding people but also to limit the kinds of libraries needed and setup. To your point, frameworks such as Spring have built-in functionality, but I think it is always good to understand the concepts and then you can research how your chosen framework implements a concepts. Or if they don't, you already have a solution
2 years ago
Cross Site Scripting (XSS) if you do not fix it on your site it gets loaded into the user's browser and can be leveraged by the attacker. Either they get tricked into clicking a link which uses XSS to pretend to its legitimate traffic from your site or stored XSS where it gets embedded somewhere (forum, etc.) and triggered at a later date. Even worse if the XSS can be used to extract cookies or session data, the attacker can leverage to Cross Site Request Forgery (CSRF) to reuse that data and pretend to be the legit user.
2 years ago
Some frameworks like Spring have methods for filtering.

You can also use the OWASP Encoder project library which has many methods depending on the data you are working with:
https://owasp.org/www-project-java-encoder/

cleanData = Encode.forHtmlContent(UNTRUSTED)
Encode.forHtmlAttribute(UNTRUSTED)
...URL...
...REST...
and more. Check out the How to Use tab

2 years ago
First, sending login credentials in a GET request in the URL is not a good practice. Depending on your logging in the app or on the web server, those credentials may be written in plain text into the audit file. If this is a guest account without credentials then it is not as big of an issue. Normally you want to authentication with a POST request.

For a guest user, I would probably just register the session id and use that to store temporary information while your process. I would be a little cautious about mixing non-logged in, guest user data into a database with sessions for valid users since there is a chance for mistakes.
2 years ago
One of the best things to do is embed security into the development process since it is cheaper to fix issues before the go through testing or are deployed into production.

You can embed free tools like SpotBugs or SonarLint into the IDE which will highlight bugs as your are developing.
Other tools like OWASP Dependency Check help you identify insecure libraries you are loading into your project. You can also embed into the IDE or into the build process like Maven, Jenkins, etc.
https://owasp.org/www-project-dependency-check/
2 years ago
Thanks everyone. The book is in a liveProject form where you work through a project and Manning also provides online access to different books with a similar topic. There is not a physical version of the book.
2 years ago
Deepak,

There are plenty of good SQL Injection resources. Carnegie Mellon SEI has a great site with plenty of Java Security examples of non-compliant code and how to fix:
https://wiki.sei.cmu.edu/confluence/display/java/IDS00-J.+Prevent+SQL+injection
2 years ago
As Tim mentioned, PreparedStatement is the way to protect from SQL Injection. A small caveat, you can still do it wrong and not get the full protection. For example:

String sql = "SELECT COUNT(task_name) FROM schedule WHERE task_name = '" + taskName + "'";                                                                
PreparedStatement stmt = connection.prepareStatement(sql));


This is wrong because you aren't using the variable replacement and still putting user input directly into the query without the strong typing. It should be:

String sql = "SELECT COUNT(task_name) FROM schedule WHERE task_name = ?";
PreparedStatement stmt = connection.prepareStatement(sql);
stmt.setString(1, taskName);

2 years ago
I added the csrfguard.js and csrfguard.properties (referenced later in the web.xml). Then the Owasp.CsrfGuard.overlay.properties file all into the a web app directory. The .js and .properties from csrfguard I did not change. The overlay was mostly standard, is called from csrfguard.properites and looks like this:
org.owasp.csrfguard.configuration.provider.factory=org.owasp.csrfguard.config.overlay.ConfigurationOverlayProviderFactory

org.owasp.csrfguard.JavascriptServlet.refererPattern = http://localhost:80.*

org.owasp.csrfguard.unprotected.Default=%servletContext%/
org.owasp.csrfguard.unprotected.Upload=%servletContext%/upload.html
org.owasp.csrfguard.unprotected.JavaScriptServlet=%servletContext%/JavaScriptServlet
org.owasp.csrfguard.unprotected.Ajax=%servletContext%/ajax.html
org.owasp.csrfguard.unprotected.Error=%servletContext%/jsp/accessdenied.jsp
org.owasp.csrfguard.unprotected.Index=%servletContext%/index.html
org.owasp.csrfguard.unprotected.JavaScript=%servletContext%/javascript.html
org.owasp.csrfguard.unprotected.Tag=%servletContext%/tag.jsp
org.owasp.csrfguard.unprotected.Redirect=%servletContext%/redirect.jsp
org.owasp.csrfguard.unprotected.Forward=%servletContext%/forward.jsp
org.owasp.csrfguard.unprotected.Session=%servletContext%/session.jsp
org.owasp.csrfguard.unprotected.Favicon=%servletContext%/favicon.ico


Then finally to get it all working you can add a filter in your web.xml which tells CSRFGuard to inject the token and also check it. This is where the mapping go for the .js and .properties file. For example:
<webapp>
...
  <filter>
     <filter-name>CSRFGuard</filter-name>
     <filter-class>org.owasp.csrfguard.CsrfGuardFilter</filter-class>
  </filter>
  <filter-mapping>
     <filter-name>CSRFGuard</filter-name>
     <url-pattern>/app</url-pattern>
  </filter-mapping>
  <listener>
     <listener-class>org.owasp.csrfguard.CsrfGuardServletContextListener</listener-class>
  </listener>
  <listener>
     <listener-class>org.owasp.csrfguard.CsrfGuardHttpSessionListener</listener-class>
  </listener>
  <context-param>
     <param-name>Owasp.CsrfGuard.Config</param-name>
     <param-value>WEB-INF/csrfguard.properties</param-value>
  </context-param>
  <context-param>
     <param-name>Owasp.CsrfGuard.Config.Print</param-name>
     <param-value>true</param-value>
  </context-param>
  <servlet>
     <servlet-name>CsrfServlet</servlet-name>
     <servlet-class>org.owasp.csrfguard.servlet.JavaScriptServlet</servlet-class>
     <init-param>
        <param-name>source-file</param-name>
        <param-value>WEB-INF/csrfguard.js</param-value>
     </init-param>
     <init-param>
        <param-name>inject-into-forms</param-name>
        <param-value>true</param-value>
     </init-param>
     <init-param>
        <param-name>inject-into-attributes</param-name>
        <param-value>true</param-value>
     </init-param>
     <init-param>
        <param-name>domain-strict</param-name>
        <param-value>false</param-value>
     </init-param>
     <init-param>
        <param-name>referer-pattern</param-name>
        <param-value>.*localhost.*</param-value>
     </init-param>
  </servlet>
  <servlet-mapping>
     <servlet-name>CsrfServlet</servlet-name>
     <url-pattern>/csrfguard</url-pattern>
  </servlet-mapping>
</web-app>
2 years ago