Forem: Dawn Zhao

Golang Security Review Guide

Dawn Zhao — Thu, 22 Aug 2024 09:08:25 +0000

Written by Abdullah Al-Sultani
Linkedin:Abdullah Al-Sultani
Mailbox📮:abdullah@alsultani.me

Go is a statically typed, compiled high-level programming language designed at Google. It is syntactically similar to C, but with memory safety, garbage collection, structural typing, and CSP-style concurrency. Most of our apps and backend rely on Golang. Therefore, we found it important to document the review process for such applications. The checklist of this article can be found at the end of the page.

First things first

Go by Example

Go related

In golang, the library net/http usually transforms the path to a canonical one before accessing it:
- /flag/ -- Is responded with a redirect to /flag
- /../flag --- Is responded with a redirect to /flag
- /flag/. -- Is responded with a redirect to /flag
If the CONNECT method is used, this doesn't happen. So, if you need to access some protected resource, you can abuse this trick: curl --path-as-is -X CONNECT http://hack.me/../flag
go =< 1.15 has an issue with Range header that can be exploited in some contexts https://github.com/golang/go/issues/40940
When go parses a JSON response, it sets the non-existent fields that are defined as strings as empty strings instead of nil.

What you are looking for

Vulnerable 3rd-Party Modules

You can use https://docs.snyk.io/getting-started/quickstart
Simply running snyk test on a Go application will parse your modules and report back any known CVEs, as well as info about any fixed versions of them that you can upgrade to.

RCE - Remote Code Execution

Command injection occurs when the user input gets executed on the server as system command. For instance, look at the following code:

binary, lookErr := exec.LookPath("sh")
  if lookErr != nil {
      panic(lookErr)
}
env := os.Environ()
args := []string{"sh", "-c", req.FormValue("name")}
execErr := syscall.Exec(binary, args, env)
if execErr != nil {
    panic(execErr)
}

Most of the time, the application gets user input through forms. The code above receives the name value from a form and passes it to the dangerous function syscall.Exec which will execute the command on the server. However, when the developer expects a name, the attacker can submit something like
John & whoami > /var/www/static/whoami.txt
This command will store the output of whoami in whoami.txt in the static folder. Golang offers many to execute commands to list a few of them:

exec.Command()
exec.CommandContext()
syscall.Exec()
os.StartProcess()
exec.Cmd()

Getting any user controlled input inside these functions directly without validating is extremely dangerous. Make sure to filter the input or use allow-list the commands that want to be executed like the following:

type OSProgram uint64

const (
    LS OSProgram = iota
    Cat
    Echo
    Grep
)

func CallOSCommand(program OSProgram, args ...string) {
    switch program {
    case LS:
        exec.Command("ls", args...)
    case Cat:
        exec.Command("cat", args...)
    case Echo:
        exec.Command("echo", args...)
    case Grep:
        exec.Command("grep", args...)
  }
}

SQL Injection

Sql injection occurs when user input is being inserted into the sql query without filtering or sanitizing. The root cause of this issue is old practice, which is string concatenation.

ctx := context.Background() 
customerId := r.URL.Query().Get("id") 
query := "SELECT number, cvv FROM creditcards WHERE customerId = " + customerId 
row, _ := db.QueryContext(ctx, query)

As you can notice, the customerId is user-supplied input. And it is being added to the query without any filteration. What if an attacker submits customerId as 1 or 1=1?
The sql query will become:

SELECT number, cvv FROM creditcards WHERE customerId = 1 or 1=1

This will dump the full table records since 1 or 1=1 is always true. The solution for this issue is called Prepared Statments. The safe code will look like this:

ctx := context.Background() 
customerId := r.URL.Query().Get("id") 
query := "SELECT number, expireDate, cvv FROM creditcards WHERE customerId = ?" 
stmt, _ := db.QueryContext(ctx, query, customerId)

Notice the placeholder ? . Your query is now:

Readable
Safe
And short

The placeholder syntax is database-specific. You may see the following syntaxes depending on the project requirements:

MySQL
WHERE col = ?
VALUES(?, ?, ?)

PostgreSQL
WHERE col = $1
VALUES($1, $2, $3)

Oracle
WHERE col = :col
VALUES(:val1, :val2, :val3)

❗️GORM can cause SQL injection even if the prepare statement is being used. If you pass string parameters to numerical IDs, for example,

userInput := "jinzhu;drop table users;"

// safe, will be escaped
db.Where("name = ?", userInput).First(&user)

// SQL injection
db.Where(fmt.Sprintf("name = %v", userInput)).First(&user)

// will be escaped
db.First(&user, "name = ?", userInput)

// SQL injection
db.First(&user, fmt.Sprintf("name = %v", userInput))

userInputID := "1=1;drop table users;"
// safe, return error
id,err := strconv.Atoi(userInputID)
if err != nil {
    return error
}
db.First(&user, id)

// SQL injection
db.First(&user, userInputID)
// SELECT * FROM users WHERE 1=1;drop table users;

// SQL injection
db.Select("name; drop table users;").First(&user)
db.Distinct("name; drop table users;").First(&user)
db.Model(&user).Pluck("name; drop table users;", &names)
db.Group("name; drop table users;").First(&user)
db.Group("name").Having("1 = 1;drop table users;").First(&user)
db.Raw("select name from users; drop table users;").First(&user)
db.Exec("select name from users; drop table users;")
db.Order("name; drop table users;").First(&user)

String concatenation functions and methods

💡Always take a deep look when reviewing string concatenation process inside a function. Most of the time, developer forgets about possible security issues. Whenever you see non-standard SQL query generator there is a possibility of SQL injection.

Function/Method & Example：
Plus operator：
name := "A" + " " + "b" // A b
String append:
u := "This"
v := " is working."
u += v // sets u to "This is working."
Join() function:
s := []string{"This", "is", "a", "string."}
v := strings.Join(s, " ")
fmt.Println(v) // This is a string.
Sprintf() method:
s1 := "abc"
s2 := "xyz"
v := fmt.Sprintf("%s%s", s1, s2)
fmt.Println(v) // abcxyz
Bytes buffer method:
var b bytes.Buffer
b.WriteString("abc")
b.WriteString("def") // append
fmt.Println(b.String()) // abcdef
Strings builder method:
var sb strings.Builder
sb.WriteString("First")
sb.WriteString("Second")
fmt.Println(sb.String()) // FirstSecond
Repeat() Method:
fmt.Println(strings.Repeat("abc", 3)) // abcabcabc

Real life case
Our colleague Anton found an interesting SQL injection vulnerability in the well known SQL library. As we stated before, the root cause of the issue was insecure string concatenation.
The vulnerable code was in gen_sql.go which is used to generate the SQL query, the vulnerable snippet:

switch c.value.(type) {
        case []interface{}:
                s := []string{}
                tempInter := c.value.([]interface{})
                if len(c.value.([]interface{})) == 0 {
                        return ""
                }
                if len(tempInter) == 0 {
                        return ""
                }
                if len(tempInter) > LIST_LIMIT {
                        tempInter = tempInter[:LIST_LIMIT]
                }
                for _, i := range tempInter {
                        vv := fmt.Sprintf("%v", i)
                        switch i.(type) {
                        case string:
                                vv = fmt.Sprintf("'%v'", i)
                        }
                        s = append(s, vv)
                }
                v = QuoteJoinString(s, "%v", ",")
        case []string:
                v = fmt.Sprintf("'%v'", c.value)

The code does the following:

It checks the data type of c
Then, if it is an array of interface it appends the data (the string) to the query without escaping it.
Similarly, for string data type.

package main

import (
    "fmt"

    "code.byted.org/dp/clickhouse_client_golang"
)

func main() {

        userData := "test' or title = 'test" // user-controlled input 

    sql := clickhouse_client_golang.NewSqlGenerator().
        AddSelect("title").
        From("table").
        AddWhereCond(clickhouse_client_golang.NewCond("title = ?", []interface{}{userData})).
        AddWhereCond(clickhouse_client_golang.NewCond("title = ?", userData)).
        Sql()

    fmt.Println(sql)
}

Basically, it will escape the AddWhereCond function prepare statement. It will generate the following query:

select title from table where (title = 'test' or title = 'test') and (title = 'test' or title = 'test')

XSS - Cross Site Scripting

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
There are three types of XSS:
Reflected XSS Attacks
Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other website. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser. The browser then executes the code because it came from a “trusted” server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-I XSS (the attack is carried out through a single request / response cycle).
Stored XSS Attacks
Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-II XSS.
DOM XSS Attacks
DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment. This is in contrast to other XSS attacks (stored or reflected), wherein the attack payload is placed in the response page (due to a server side flaw).
The following code is vulnerable to Reflected XSS:

package main 
import "net/http" 
import "io" 
func handler (w http.ResponseWriter, r *http.Request) {
    io.WriteString(w, r.URL.Query().Get("param1")) 
} 
func main () {
    http.HandleFunc("/", handler) 
    http.ListenAndServe(":8080", nil)
}

As Content-Type HTTP response header is not explicitly defined, Go http.DetectContentType default value will be used, which follows MIME Sniffing standard. The io.WriteString will return the user input param1 as it is without filteration or sanitization. Going to http://127.0.0.1:8080/?param1=%3Cscript%3Ealert(1)%3C/script%3E will cause XSS.

Dangerous functions:

template.HTML()
template.HTMLAttr()
template.CSS()
template.JS()
template.JSStr()
template.Srcset()
template.URL()
fmt.Fprintf()
io.WriteString()
writer.Write()

SSRF - Server Side Request Forgery

If the application makes HTTP requests to URL provided by untrused source (such as user), and no protection is implemented, then it might be vulnerable to SSRF attacks. The attacker can send a request to the internal network or the server's localhost. The outcome can differ from one case to another. For example, an attacker can use the server to send requests to bypass certain firewall rules that mark the vulnerable server as trusted service.
In Go, we can use the net/http package in order to help us make our own HTTP requests. Here are a few examples:
http.X

resp, err := http.Get("http://example.com/")
...
resp, err := http.Post("http://example.com/upload", "image/jpeg", &buf)
...
resp, err := http.PostForm("http://example.com/form",
        url.Values{"key": {"Value"}, "id": {"123"}})

For control over HTTP client headers, redirect policy, and other settings, create a Client:

client := &http.Client{
        CheckRedirect: redirectPolicyFunc,
}

resp, err := client.Get("http://example.com")
// ...

req, err := http.NewRequest("GET", "http://example.com", nil)
// ...
req.Header.Add("If-None-Match", `W/"wyzzy"`)
resp, err := client.Do(req)
// ...

A vulnerable code snippet, the following code gets user input and passes it to http.Get directly:

package main

import (
   "io/ioutil"
   "log"
   "net/http"
)

func main() {
   userControllerd := "http://localhost:8000"
   resp, err := http.Get(userControllerd)
   if err != nil {
      log.Fatalln(err)
   }
   //We Read the response body on the line below.
   body, err := ioutil.ReadAll(resp.Body)
   if err != nil {
      log.Fatalln(err)
   }
   //Convert the body to type string
   sb := string(body)
   log.Printf(sb)
}

Fixing SSRF could be tricky. You need to validate the address before connecting to it. However, this must be done at a low layer to be effective to prevent DNS Rebinding attacks.

File Inclusion

The ability to read files on the server by accepting filename or file path from user-controlled input. The following function is vulnerable to this kind of attack.

const ROOT string = "/path/to/root/%s"
func getFileByName(file_name string) string { // fine_name is controlled by user 
   path := fmt.Sprintf(ROOT, file_name)
   buffer, err := ioutil.ReadFile(path)
   if err != nil {
      return name
   }
   return buffer
}

Since the file_name is controlled by user, it is possible to retrieve arbitrary files in the filesystems by the means of ../. For instance, getFileByName("../../../etc/passwd") can read the passwd file inside the linux machine. This results in the absolute path /path/to/root/../../../etc/passwd, and its canonicalized form /etc/passwd. To remediate vulnerability, the path variable can be safely built as follows:

path := fmt.Sprintf(ROOT, path.Base(file_name))

If the app uses path.Base or other checks before passing it to the ioutil.ReadFile it is considered to be secure unless the checks are insufficient or bypassable.

filepath.Join()
filepath.Clean()

Demonstrated by several bug reports, filepath.Join() is a common culprit for directory traversal vulnerabilities. The reason might be that the documentation is a little misleading.
Real life example
A good example of this issue is CVE-2021-43798. Let's explore it.
The vulnerable code was

// /public/plugins/:pluginId/*
func (hs *HTTPServer) getPluginAssets(c *models.ReqContext) {
        pluginID := web.Params(c.Req)[":pluginId"]
        plugin, exists := hs.pluginStore.Plugin(c.Req.Context(), pluginID)
        if !exists {
                c.JsonApiErr(404, "Plugin not found", nil)
                return
        }

        requestedFile := filepath.Clean(web.Params(c.Req)["*"])
        pluginFilePath := filepath.Join(plugin.PluginDir, requestedFile)

        if !plugin.IncludedInSignature(requestedFile) {
                hs.log.Warn("Access to requested plugin file will be forbidden in upcoming Grafana versions as the file "+
                        "is not included in the plugin signature", "file", requestedFile)
        }

        // It's safe to ignore gosec warning G304 since we already clean the requested file path and subsequently
        // use this with a prefix of the plugin's directory, which is set during plugin loading
        // nolint:gosec
        f, err := os.Open(pluginFilePath)
        if err != nil {
                if os.IsNotExist(err) {
                        c.JsonApiErr(404, "Plugin file not found", err)
                        return
                }
                c.JsonApiErr(500, "Could not open plugin file", err)
                return
        }
        defer func() {
                if err := f.Close(); err != nil {
                        hs.log.Error("Failed to close file", "err", err)
                }
        }()
        fi, err := f.Stat()
        if err != nil {
                c.JsonApiErr(500, "Plugin file exists but could not open", err)
                return
        }

As we can see, the user-controlled value was being passed to filepath.Clean() function in order to clean it from ... However, it only does that (remove the traversal) when the value starts with a forward slash (/). Then, the value got passed to filepath.Join() which will normalize the path with the predefined plugin.PluginDir value. The attacker could use ../ to traverse the filesystem.
*Exploit: *
To read /etc/passwd content, you had to send the following request:
curl --path-as-is http://localhost:3000/public/plugins/alertlist/../../../../../../../../etc/passwd

XXE - XML External Entity

Go is shipped with native XML parser encoding/xml that is not vulnerable to XXE. However, parse is used to mere XML parsing and manipulating. It doesn't come with advanced features like validation. Therefore, sometimes developers use third party libraries such as libxml2. Here is an example,

// open the form file
file, err := c.FormFile("xml")
xml, err := file.Open()
defer xml.Close()

// parse the XML body
p := parser.New(parser.XMLParseNoEnt)
doc, err := p.ParseReader(xml)
defer doc.Free()

// use the XML document and return data to the user...

If XXE is enabled in the configuration (parser.XMLParseNoEnt is set in the parser), and the user can control the XML input data. They can send the following XML

<!DOCTYPE d [<!ENTITY e SYSTEM "file:///etc/passwd">]><t>&e;</t>

After the file content gets parsed through ParseReader the response will retrieve the content of /etc/passwd

💡Parsing of external entities is disabled by default. Make sure to check that before jumping to conclusions.

Authentication

Password storing

The first rule you need to know is to never store the plaintext of the user's password. For security reasons, you need to use a one-way function to generate a hash for the given password and you can store this hash. The password needs to include salt and/or pepper before storing it, to make sure no two users have the same hash even if they use the same password. Let's take a look at the following code:

package main

import (
        "context"
        "crypto/rand"
        "crypto/md5"
)

func main() {
        ctx := context.Background()
        email := []byte("john.doe@somedomain.com")
        password := []byte("47;u5:B(95m72;Xq")
        // create random word
        salt := "RandomValue123ABC"
        // let's create MD5(salt+password)
        h := md5.New()
        io.WriteString(h, salt)
        io.WriteString(h, password)
        h := hash.Sum(nil)
        // this is here just for demo purposes
        //
        // fmt.Printf("email : %s\n", string(email))
        // fmt.Printf("password: %s\n", string(password))
        // fmt.Printf("salt : %x\n", salt)
        // fmt.Printf("hash : %x\n", h)
        // you're supposed to have a database connection
        stmt, err := db.PrepareContext(ctx, "INSERT INTO accounts SET hash=?, salt=?, email=?")
        if err != nil {
                panic(err)
        }
        result, err := stmt.ExecContext(ctx, h, salt, email)
        if err != nil {
                panic(err)
        }
}

The code above has many issues. First, it uses MD5 which is cryptographically broken and should not be used for secure applications. And salt (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 safeguard passwords in storage.) is a constant value. The hashing algorithms recommended by OWASP are bcrypt , PDKDF2 , Argon2 and scrypt. These will take care of hashing and salting passwords in a robust way. Any use for in-house built in logic needs a deep look because of the golden rule in crypto: never roll your own crypto!

Logic

Many issues occur while validating the user input before authenticating. Let's take a vulnerable example:

func check(u, p string) bool {
  password:= tt.GetUser(u).password
  user:= tt.GetUser(u)
  if u == user || p == password {
    return true 
  }
  return false
}

The previous code makes an illogical mistake. The OR operator returns true if one of the cases is true. Since the user exists in TT database, the following check will return true even if the password is wrong.
Let's take another example:

func auth(fn http.HandlerFunc) http.HandlerFunc {
  return func(w http.ResponseWriter, r *http.Request) {
    user, pass, _ := r.BasicAuth()
    if !check(user, pass) {
       w.Header().Set("WWW-Authenticate", "Basic realm=\\"MY REALM\\"")
       http.Error(w, "Unauthorized.", 401)
       // return needs to be here to fix this issue 
    }
    fn(w, r)
  }
}
func check(u, p){
    [...]
}
func handler(w http.ResponseWriter, r *http.Request) {
    [...]
}

func main() {
    http.HandleFunc("/",auth(handler))
    log.Fatal(http.ListenAndServe(":8080", nil))
}

auth function has no return when the check fails. So, in both cases, it will trigger the callback function handler.

Sessions control

The flow of session process could be seen in the following image

Let's talk about session generating. The function below for example:

// create a JWT and put in the clients cookie 
func setToken(res http.ResponseWriter, req *http.Request) {
     ...
}

You need to make sure that the session identifier is generated randomly, so it stays reliable against brute-forcing.

token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims) 
signedToken, _ := token.SignedString([]byte("secret")) //our secret

Now that we have a sufficiently strong token, we must also set the Domain, Path , Expires , HTTP only , Secure for our cookies. In this case, the Expires value is, in this example, set to 30 minutes since we are considering our application a low-risk application.

// Our cookie parameter
cookie := http.Cookie{
Name: "Auth",
Value: signedToken,
Expires: expireCookie,
HttpOnly: true,
Path: "/",
Domain: "127.0.0.1",
Secure: true
}
http.SetCookie(res, &cookie) //Set the cookie

Upon sign-in, a new session is always generated. The old session is never re-used, even if it is not expired. This will protect the application from Session Fixation. Furthermore, session identifiers should never be exposed in URL's. They should only be located in the HTTP cookie header.

Access Control

When a user tries to access authorization decisions, it must be checked if they are authorized to perform these actions. Access control highly relies on business logic. In case of a failure, access control should fail securely. In Go we can use defer to achieve this. Important operations where access controls must be enforced in order to prevent an unauthorized user from accessing them are as follows:

File and other resources
Protected URL's
Protected functions
Direct object references
Services
Application data
User and data attributes and policy information.

If any action is being taken, you must check the user capabilities before executing the action. For example,

func main() {
    // Init the mux router
    router: = mux.NewRouter()
    // Route handles & endpoints
    // Get all books
        router.HandleFunc("/books/", GetBooks).Methods("GET")
    // Create a book
        router.HandleFunc("/books/", CreateBook).Methods("POST")
    // Delete a specific book by the bookID
        router.HandleFunc("/books/{bookid}", DeleteBook).Methods("DELETE")
    // Delete all books
        router.HandleFunc("/books/", DeleteBooks).Methods("DELETE")
    // serve the app
        fmt.Println("Server at 8080")
    log.Fatal(http.ListenAndServe(":8000", router))
}

If the code triggers any of the callback functions without checking, the user has the ability to create, delete, or perform any other action. This code is vulnerable to Broken Access Control.

Cryptography

Read: https://docs.google.com/presentation/d/1gMvkF-Tew1H9oF3Lh2IeQpOkk3bzSpE_TUj00hoztBE/edit#slide=id.g228b0426239_0_3201

Block ciphers can only encrypt a fixed size of data. To encrypt more, one needs a block cipher mode of operation
Unfortunately, most modes are insecure: ECB, CBC, CTR, CFB, etc. Depending on the usage, you can easily recover or modify the plaintext
The most common stream cipher RC4 also allows you to modify, and, in certain cases (WEP), recover the plaintext

Hashing

Make sure that the hashing function is secure against Preimage attack, Birthday attack, ...etc. A list of insecure hash algorithms:

MD2
MD4
MD5
SHA-0
SHA-1
Panama
HAVAL (disputable security, collisions found for HAVAL-128)
Tiger (disputable, weaknesses found)
SipHash (it is not a cryptographic hash function)

List of secure hashing functions:

SHA-2, SHA-256, SHA-512
SHA-3, SHA3-256, SHA3-512, Keccak-256
BLAKE2 / BLAKE2s / BLAKE2b
RIPEMD-160

package main

import (
        "crypto/md5"
        "crypto/sha256"
        "fmt"
        "io"

        "golang.org/x/crypto/blake2s"
)

func main() {
        h_md5 := md5.New() // insecure 
        h_sha := sha256.New() // secure but not for password without salt
        h_blake2s, _ := blake2s.New256(nil) // secure 
        io.WriteString(h_md5, "Welcome to Go Language Secure Coding Practices")
        io.WriteString(h_sha, "Welcome to Go Language Secure Coding Practices")
        io.WriteString(h_blake2s, "Welcome to Go Language Secure Coding Practices")
        fmt.Printf("MD5 : %x\n", h_md5.Sum(nil))
        fmt.Printf("SHA256 : %x\n", h_sha.Sum(nil))
        fmt.Printf("Blake2s-256: %x\n", h_blake2s.Sum(nil))
}

Pseudo-random generators

Generating random numbers is not obvious as it seems. For example,

package main
import (
        "fmt"
        "math/rand"
)
func main() {
        fmt.Println("Random Number: ", rand.Intn(1984))
}

Running this code several times will show the following output:

$ for i in {1..5}; do go run rand.go; done
Random Number: 1825
Random Number: 1825
Random Number: 1825
Random Number: 1825
Random Number: 1825

Why does it generate the same value every time?

Because Go's math/rand is a deterministic pseudo-random number generator. Similar to many others, it uses a source, called a Seed. This Seed is solely responsible for the randomness of the deterministic pseudo-random number generator. If it is known or predictable, the same will happen in generated number sequence. This behavior could be fixed easily by using the math/rand Seed funciton.

❗️math/rand is not safe to generate tokens, passwords, keys and other random values.

rand package - crypto/rand - Go Packages must be used to generate random values instead of math/rand.

Error Handling and Logging

Error handling

When dealing with error logs, developers should ensure no sensitive information is disclosed in the error responses, as well as guarantee that no error handlers leak information (e.g. debugging, or stack trace information).

Logging

All logging should be implemented by a master routine on a trusted system, and the developers should also ensure no sensitive data is included in the logs (e.g. passwords, session information, system details, etc.), nor is there any debugging or stack trace information. Additionally, logging should cover both successful and unsuccessful security events, with an emphasis on important log event data.
An example of this is logging Access Tokens of users in OAuth flow.

OpenConfigPost("/passport/path/to/function/v2/", antispam(this), open.AccessTokenHandlerV2),

func AccessTokenHandlerV2(ctx *gin.Context) {
    accessTokenParam, err := oauth2.GetAccessTokenRequestParam(ctx)
    logs.CtxInfo(ctx, "[AccessTokenHandlerV2] %v", oauth2.GetRequestString(accessTokenParam))
    /* ... */
    token, perr := rpcHandlers.PassportOpenService.GetAccessTokenV2(ctx,
        accessTokenParam.GetClientKey(), accessTokenParam.GetClientSecret(),
        accessTokenParam.GetAuthorizationCode(), accessTokenParam.GetGrantType(),
        accessTokenParam.RedirectURI, accessTokenParam.GetAppId())
    logs.CtxInfo(ctx, "[GetAccessTokenV2] %v", token.String())
}

type AccessTokenRequestParam struct {
    ClientKey         string `json:"client_key"`
    GrantType         string `json:"grant_type"`
    ClientSecret      string `json:"client_secret"`
    AuthorizationCode string `json:"code"`
    RedirectURI       string `json:"redirect_uri"`
    AppId             int32
}

The code above was storing the ClientSecret and AuthorizationCode in the log file, which is insecure practice.
Important event data most commonly refers to all:

input validation failures.
Authentication attempts, especially failures.
Access control failures.
Apparent tampering events, including unexpected changes to state data.
Attempts to connect with invalid or expired session tokens.
System exceptions.
Administrative functions, including changes to security configuration settings.
Backend TLS connection failures and cryptographic module failures.

CSRF - Cross-Site Request Forgery

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated.
Let's say that foo.com uses HTTP GET requests to set the account's recovery email as shown:

GET https://foo.com/account/recover?email=me@somehost.com

The victim is authenticated at https://foo.com
Attacker sends a chat message to the victim with the following link: https://foo.com/account/recover?email=me@attacker.com
Victim's account recovery email address is changed to me@attacker.com , giving the attacker full control over it.

The following code is vulnerable to CSRF

package main

import (
        "net/http"
)

func main() {
        r := mux.NewRouter()
        r.HandleFunc("/signup", ShowSignupForm)
        r.HandleFunc("/signup/post", SubmitSignupForm)
        http.ListenAndServe(":8000") // No CSRF protection middleware
}
func ShowSignupForm(w http.ResponseWriter, r *http.Request) {

}
func SubmitSignupForm(w http.ResponseWriter, r *http.Request) {
         // Do Stuff 
}

Regular Expressions

Regular Expressions are a powerful tool that's widely used to perform searches and validations. Writing ReGex is a hard task and many developers make mistakes while writing it that could lead to security issues.

ReDoS

Regular Expression Denial of Service (ReDoS) is an algorithmic complexity attack that provokes a Denial of Service (DoS). ReDos attacks are caused by a regular expression that takes a very long time to be evaluated, exponentially related to input size. This exceptionally long time in the evaluation process is due to the implementation of the regular expression in use, for example, recursive backtracking ones.
To fully understand the ReDos attack, please read the following article: https://blog.doyensec.com/2021/03/11/regexploit.html
To detect evil regex use this website: https://devina.io/redos-checker

Faulty regexes

Regex is used for a lot of security checks such as:

Firewall rules
Input validation
Malware detection
...

Incorrectly deployed regex may cause security issues. For instance,
SSRF protection via a blacklist
The following regex is being used to detect internal IP addresses ^http?://(127\.|10\.|192\.168\.).*$

package main

import (
    "bytes"
    "fmt"
    "regexp"
)

func main() {

    match, _ := regexp.MatchString("^http?://(127\.|10\.|192\.168\.).*$", "https://0.0.0.0")
    fmt.Println(match)

}

It fails to match a case which is 0.0.0.0 that is the local IP. Learn regex in order to find wrongly configured regex.
Another example,

package main

import (
    "bytes"
    "fmt"
    "regexp"
)
func main() {
    path := "[USER_INPUT]"  
    match, _ := regexp.MatchString("^[\a-zA-Z0-9_]*", url)
    if match {
    // Send request 
      var url = "https://api.github.com" + path;
     ... 
    }
}

The URL https://api.github.com does not end with a /. An attacker can thus send the request to any server via path=.attacker.com/hello, resulting in https://api.github.com.attacker.com/hello. When an attacker uses this to redirect the request to their server, the Authorization header gets leaked.
To perform this attack, path must match the regular expression ^[/a-zA-Z0-9_]*. Looking at the regex, we see that the character * is a greedy quantifier, indicating that any amount of matches is allowed, including zero. The payload .attacker.com/hello does not match the pattern ^[/a-zA-Z0-9_]*, but since zero matches are allowed by the * quantifier, an attacker can use an arbitrary string as a payload.

Checklist

RCE
- Anywhere that a system command is being executed
- exec.Command()
- exec.CommandContext()
- syscall.Exec()
- os.StartProcess()
- exec.Cmd()
SQL injection
- String concatenation: Plus operator,String append, join() function, Sprintf() method, Bytes buffer method, Strings builder method, and Repeat() Method.
Vulnerable 3rd-Party Modules
- Use Snyk https://docs.snyk.io/getting-started/quickstart
XSS
- Using the text/template package
- Dangrous functions:
- template.HTML()
- template.HTMLAttr()
- template.CSS()
- template.JS()
- template.JSStr()
- template.Srcset()
- template.URL()
- fmt.Fprintf()
- io.WriteString()
- writer.Write()
SSRF
- http.X
- client.X
File inclusion
- ioutil.ReadFile()
- filepath.Join()
- filepath.Clean()
XXE
- libxml2
- parser.XMLParseNoEnt
Auth
- Password storing
- Logic
- Session
- Unpredictable
- New after login
Access control
- Logic
- Understand the task in hand and the threat model of it.
Cryptgraphy
- Hashing
- Insecure algorithms such as MD5, SHA-1,...etc
- No salt or fixed salt
- Pseudo-Random Generators
- Math/rand to generate random numbers
- ECB, CBC, CTR, and CFB
- AES-GCM
- Password-based Encryption (RFC 2898)
- RSA PKCS v1.5 Encryption
- ECDSA
Error Handling and Logging
- Error handling
- No sensitive information is disclosed in error responses
- No debug information
- Logging
- Ensure no sensitive data is included in the logs (e.g. passwords, session information, system details, etc.
CSRF
- No CSRF protection middleware
Regular expression
- Fuzz
- Test evil regex: https://devina.io/redos-checker
- Understand the expected output

Study materials

Sponsored by MarsCode
Welcome to join our Discord to discuss your ideas with us.

MarsCode Follow

MarsCode provides an AI-powered IDE and an AI extension to assist your programming tasks.

5 Javascript Tips You Should Know

Dawn Zhao — Mon, 19 Aug 2024 08:28:31 +0000

Written by Joab Chua

1. Console.log

Add colour to your console log

Stop doing just this! ❌

Try this instead. ✅

But if you have an array of objects, try this would be even better 😎

If you want to measure how fast certain operations run in your code, try this.

Do console.time and console.timeEnd to measure the time taken in the browser console.
Lastly, if you want to trace your code and its execution sequence, try this.

You will be able to see tonnes of info that you need to debug your application.

2. Object de-structuring

Did it happened to you before that you only need a few variables in the object but you are being passed the full object and using it in this conventional way?

Repeatedly using the human object declaration in your function? Don’t do this. Use ES6 object de-structuring instead. ✅

De-structure the variables that you need to use in the function arguments. Alternatively, you can de-structure inside the function itself.

3. Template Literal

❌ Don’t do this when you are trying to piece your variables with string.

Do this instead. ✅

4. Spread operator

Let’s say you have 2 object and you want to combined them or assign some of the properties of 1 object to another. Traditionally, we will do this.

There is technically nothing wrong with that, except that you are actually mutating your object. Try this instead. ✅

Best thing of spread operator is that it works for array as well. 😎
Instead of this.

Do this instead.

5. loops

Are you guilty of doing for loop this way to calculate the total amount of the cost in an array? Stop doing this. ❌

Start to change your style to this instead.

Clean and lean. Job done! ✅

Summary

Hope that these few tips will guide you along to write better, cleaner and leaner code.

Sponsored by MarsCode
Welcome to join our Discord to discuss your ideas with us.

MarsCode Follow

MarsCode provides an AI-powered IDE and an AI extension to assist your programming tasks.

Unlock the Power of Real-Time UI: A Beginner's Guide to Streaming Data with React.js, gRPC, Envoy, and Golang

Dawn Zhao — Thu, 08 Aug 2024 03:36:52 +0000

Written by Naveen M

Background

As part of our Kubernetes platform team, we face the constant challenge of providing real-time visibility into user workloads. From monitoring resource usage to tracking Kubernetes cluster activity and application status, there are numerous open-source solutions available for each specific category. However, these tools are often scattered across different platforms, resulting in a fragmented user experience. To address this issue, we have embraced the power of server-side streaming, enabling us to deliver live resource usage, Kubernetes events, and application status as soon as users access our platform portal.

Introduction

By implementing server-side streaming, we can seamlessly stream data to the user interface, providing up-to-date information without the need for manual refreshes or constant API calls. This approach revolutionizes user experience, allowing users to instantly visualize the health and performance of their workloads in a unified and simplified manner. Whether it's monitoring resource utilization, staying informed about Kubernetes events, or keeping tabs on application status, our server-side streaming solution brings together all the critical information in a single, real-time dashboard, but this will be applicable to anyone who wants to provide live streaming data to the user interface.
Gone are the days of navigating through multiple tools and platforms to gather essential insights. With our streamlined approach, users can access a comprehensive overview of their Kubernetes environment the moment they land on our platform portal. By harnessing the power of server-side streaming, we have transformed the way users interact with and monitor their workloads, making their experience more efficient, intuitive, and productive.
Through our blog series, we aim to guide you through the intricacies of setting up server-side streaming with technologies such as React.js, Envoy, gRPC, and Golang.

There are three main components involved in this project:
1. The backend, which is developed using Golang and utilizes gRPC server-side streaming to transmit data.
2. The Envoy proxy, which is responsible for making the backend service accessible to the outside world.
3. The frontend, which is built using React.js and employs grpc-web to establish communication with the backend.
The series is divided into multiple parts to accommodate the diverse language preferences of developers. If you're interested specifically in the role of Envoy in streaming or want to learn about deploying an Envoy proxy in Kubernetes, you can jump to the second part (Envoy as a frontend proxy in Kubernetes) and explore that aspect or just interested in the front end part, then you can just check out the front end part of the blog.
In this initial part, we'll focus on the easiest segment of the series: "How to Set Up gRPC Server-Side Streaming with Go." We are going to show sample applications with server side streaming. Fortunately, there is a wealth of content available on the internet for this topic, tailored to your preferred programming language.

PART 1: How to Set Up gRPC Server-Side Streaming with Go

It's time to put our plan into action! Assuming you have a basic understanding of the following concepts, let's dive right into the implementation:

gRPC: It's a communication protocol that allows the client and server to exchange data efficiently.
Server-side streaming: This feature is particularly useful when the server needs to send a large amount of data to the client. By using server-side streaming, the server can split the data into smaller portions and send them one by one. The client can then choose to stop receiving data if it has received enough or if it has been waiting for too long.

Now, let's start with code implementation.

Step 1: Create the Proto File
To begin, we need to define a protobuf file that will be used by both the client and server sides. Here's a simple example:



syntax = "proto3";

package protobuf;

service StreamService {
  rpc FetchResponse (Request) returns (stream Response) {}
}

message Request {
  int32 id = 1;
}

message Response {
  string result = 1;
}

In this proto file, we have a single function called FetchResponse that takes a Request parameter and returns a stream of Response messages.

Step 2: Generate the Protocol Buffer File

Before we proceed, we need to generate the corresponding pb file that will be used in our Go program. Each programming language has its own way of generating the protocol buffer file. In Go, we will be using the protoc library.
If you haven't installed it yet, you can find the installation guide provided by Google.
To generate the protocol buffer file, run the following command:



protoc --go_out=plugins=grpc:. *.proto

Now, we have the data.pb.go file ready to be used in our implementation.

Step 3: Server side implementation
To create the server file, follow the code snippet below:



package main

import (
        "fmt"
        "log"
        "net"
        "sync"
        "time"

        pb "github.com/mnkg561/go-grpc-server-streaming-example/src/proto"
        "google.golang.org/grpc"
)

type server struct{}

func (s server) FetchResponse(in pb.Request, srv pb.StreamService_FetchResponseServer) error {

        log.Printf("Fetching response for ID: %d", in.Id)

        var wg sync.WaitGroup
        for i := 0; i < 5; i++ {
                wg.Add(1)
                go func(count int) {
                        defer wg.Done()

                        time.Sleep(time.Duration(count)  time.Second)
                        resp := pb.Response{Result: fmt.Sprintf("Request #%d for ID: %d", count, in.Id)}
                        if err := srv.Send(&resp); err != nil {
                                log.Printf("Error sending response: %v", err)
                        }
                        log.Printf("Finished processing request number: %d", count)
                }(i)
        }

        wg.Wait()
        return nil
}

func main() {
        lis, err := net.Listen("tcp", ":50005")
        if err != nil {
                log.Fatalf("Failed to listen: %v", err)
        }

        s := grpc.NewServer()
        pb.RegisterStreamServiceServer(s, server{})

        log.Println("Server started")
        if err := s.Serve(lis); err != nil {
                log.Fatalf("Failed to serve: %v", err)
        }
}

In this server file, I have implemented the FetchResponse function, which receives a request from the client and sends a stream of responses back. The server simulates concurrent processing using goroutines. For each request, it streams five responses back to the client. Each response is delayed by a certain duration to simulate different processing times.
The server listens on port 50005 and registers the StreamServiceServer with the created server. Finally, it starts serving requests and logs a message indicating that the server has started.
Now you have the server file ready to handle streaming requests from clients.

Part 2

Stay tuned for Part 2 where we will continue to dive into the exciting world of streaming data and how it can revolutionize your user interface.

Sponsored by MarsCode
Welcome to join our Discord to discuss your ideas with us.

MarsCode Follow

MarsCode provides an AI-powered IDE and an AI extension to assist your programming tasks.

Personal experience sharing on Transitioning from Java to Go

Dawn Zhao — Fri, 02 Aug 2024 08:26:17 +0000

Writtern by HaojunFang

Background

I still recall when I first started learning programming, a common phrase I used to hear was: "Programming languages are just tools, the programming mindset is what matters most". However, from a practical perspective, the barriers between different languages are pretty significant. (Otherwise, wouldn't the design of these languages be in vain? 😄).
As a former Java developer, I have a high regard for Java. This probably stems from its robust ecosystem and impressive productivity. Java's syntax is clear and concise, easy to learn, and offers a great deal of flexibility and extensibility simultaneously. In addition, Java's virtual machine mechanism allows it to be cross-platform, capable of running on different operating systems, which is a tremendous advantage for developers.
However, considering the current situation, reality compelled me to learn a new language - Golang. Many companies are favoring Go, and its developers tend to have higher salaries. After almost a year of studying, using, and practicing Go, I have garnered some basic insights. I present them in this article with the hope of sharing and discussing them with you all!

Why Go

We can observe that Go is relatively low on the list, yet many companies still choose Go as their primary development language. This piqued my interest and I aim to understand the reasons behind this.

After referring to multiple documents, I concluded the following key advantages of the Go language for developers:

Powerful Concurrency: Go's Goroutines and Channels adeptly address the issues related to concurrency and asynchronous programming.
Straightforward Syntax: Go language's syntax is simpler and easier to learn than Java, which can help reduce development costs.
Efficient Memory Management: The memory management in Go is more efficient than Java, thus conserving system resources.
Cross Platform: Go allows for cross-platform compilation, enabling the operation on various operating systems. This makes business expansion and migration more convenient.

Language Features

When it comes to language features, as a former Java developer, a comparison with Java is inevitable:

Go, also known as Golang, is a static, compiled, and concurrent programming language developed by Google. It was designed with simplicity and efficiency in mind. Its features include easy learning curve, efficient concurrency, garbage collection mechanism, and a robust standard library.
Java, on the other hand, is a widely used object-oriented programming language aiming to "write once, run anywhere". It boasts cross-platform capability, object-oriented characteristics, and a rich, powerful library.

OOP

Firstly, Go is not an object-oriented language, but it can simulate object-oriented characteristics using structures and interfaces. In Go, structures hold the same level of importance as classes in object-oriented paradigms. They can contain variables and methods of various types. Object-oriented principles can be achieved through encapsulation, interfaces, and other means.

Object-oriented programming is a paradigm that encapsulates entities with similar features into a unified class form. The properties and methods within the encapsulated classes represent the common characteristics and behaviors among these entities. It primarily encompasses three characteristics: Encapsulation, Inheritance, and Polymorphism.

1. Encapsulation

In OOP, the members and methods of a class can be encapsulated, and their visibility can be controlled by access modifiers. In Go, members of a struct are exposed by default, and can be accessed outside of the struct. Strict encapsulation, like in classes, is not available. However, control of whether to export can be handled via the case of the first letter of the attribute (if not exported, it cannot be accessed externally).

package test111

type TestDto struct {
    age  string // Accessible within the package
    Name string // Accessible globally
}

2. Inheritance

In object-oriented programming languages, object inheritance is used, and in Java, the keyword "extend" is used to achieve this. In Go, inheritance relationships can be implemented using embedded structures.

package test111

type BaseRespDto struct{
    ReturnCode string
    Returnsg  string
}

type QueryOrderRespDto struct{
    BaseRespDto // After composing an anonymous base structure, the current structure can access the attribute fields of the base structure.

    OrderID     string
    OrderAmount int64
}

3. Polymorphism

OOP supports polymorphism, wherein an object can exhibit different behaviors depending on the context. While Go's structs do not directly support polymorphism, a similar effect can be achieved using interfaces. If a type implements all the methods of an interface, it can be assigned to a variable of that interface type. Polymorphism enables programs to automatically select the appropriate method implementation based on the context, thereby enhancing the flexibility and reusability of the code.

var (
    applePhone *Mobile
)

func init() {
    applePhone = NewMobile("xiaoming", "iPhone 15 Pro MAX", 1111100)
}

type USB interface {
    Storage()
    Charge() string
}

type PlayBoy interface {
    Game(name string)
}

type Mobile struct {
    User  string `json:"user"`
    Brand string `json:"brand"`
    Prise int64  `json:"prise"`
}

func NewMobile(user string, brand string, prise float64) *Mobile {
    return &Mobile{User: user, Brand: brand, Prise: prise}
}

func (m *Mobile) CallUp() {
    fmt.Printf("%s is using 💲%.2f mobile phone to make a call.\n", m.User, m.Prise)
}

func (m *Mobile) Storage() {
    fmt.Printf("%s is using a %s mobile phone to transfer data.\n", m.User, m.Brand)
}

func (m *Mobile) Charge() string {
    return fmt.Sprintf("%s is charging a %s phone.\n", m.User, m.Brand)
}

func (m *Mobile) PlayGame(name string) {
    fmt.Printf("%s is playing the game of '%s'.\n", m.User, name)
}

func TestExample(t *testing.T) {
    applePhone.Storage()
    applePhone.Charge()
    applePhone.PlayGame(applePhone.User)
}

Design Philosophy

Design Characteristics of Go
If you can't find an X feature from other languages in Go, it likely means that this feature is not suitable for Go. For instance, it might affect the compilation speed, clarity of design, or it could make the basic system particularly complex.

Less is More: If a feature does not provide significant value in solving any problem, Go will not offer it. If a feature is needed, there should be only one way to implement it.
Interface-Oriented Programming: Go proposes non-intrusive interfaces, rebutting inheritance, virtual functions and their overloading (polymorphism), and eliminating constructors and destructors.
Orthogonal + Composition: Features of the language are independent of each other, not influencing one another. For instance, types and methods are independent, so are the different types with no subclasses, and packages do not have sub-packages. Different features are loosely coupled through composition.
Concurrency Support at the Language Level: Concurrency better utilizes multi-cores and offers a robust expressiveness to simulate the real world.

Common Pitfalls & Knowledge Points at Syntax Level

Types

In addition to the common basic types, Go also has a Func() type that represents a function. This is somewhat similar to the Supplier functional interface in Java.

Branching Decision

switch-case-default

The switch-case syntax in Go is fundamentally similar to that in Java, with minor distinctions between the two. Let's clarify this with an example:

func main() {
    name := "ddd"
    switch name {
    case "xxxx":
       fmt.Println(name + "1")
    case "ddd":
       fmt.Println(name + "2")
    case "xxxxxx":
       fmt.Println(name + "3")
    default:
       fmt.Println(name + "4")
    }
}

Output Result：
ddd2

Java

public static void main(String[] args) {
    testSwitch("name");
}
private static void testSwitch(String var){
    switch (var){
        case "1":
            System.out.println(var+"1");
        case "name":
            System.out.println(var+"2");
        case "3":
            System.out.println(var+"3");
        default:
            System.out.println(var+"4");
    }
}

Output Result
name2
name3
name4

In Go, case branches do not explicitly need a break or return statement. Once a rule is met, subsequent branches won't be executed. This is due to Go's design philosophy that emphasizes simplicity and efficiency, avoiding unnecessary code redundancy.
When a switch-case statement in Go encounters a matching case, it automatically executes all the statements in that case until it bumps into the next case or default. If there is no following case or default, the program will continue to execute the following code.
This design approach simplifies the code while preventing errors that can arise from forgetting to add a break statement within a case. However, it is crucial to note that if you need to transition to the next case within a case, you can use the fallthrough keyword to achieve this.

Exported Names
Go does not have access modifiers like Java's public/private/protected/default. Instead, it uses a simple rule where the capitalization of the first letter determines if a structure/variable/method/function is exported. An exported entity, in this context, refers to whether it can be called/used by external packages.
In Go, identifiers of variables, functions, and structures that start with an uppercase letter can be accessed by code outside their package. In contrast, identifiers starting with lowercase are package-private. This is one of the design principles in Go programming language.

Error and Panic

The cumbersome error handling logic in Golang is a point of contention for many Java developers. Every error needs to be manually dealt with in the code, often using the classic if err != nil check.
Golang's panic mechanism, which leads to process exit, also tends to alarm and frustrate most developers.

In my understanding, Error in Go is somewhat analogous to RuntimeException in Java. It represents business errors that occur during runtime, which developers can manually handle. On the other hand, Panic in Go is similar to Error in Java, representing system-level errors that cannot be resolved.

Struct Creation
👍 In Go, when creating variables of struct types, built-in syntax allows for setting field values, so there's no need to manually write constructors or call a host of set methods for assignment like in Java.

Generally, there are two methods for creating an empty instance:

new(T)
&T{} —— This method is most commonly used.

Value and Reference Pass

In Golang, all parameters are passed by value, i.e., a clone of the original value. Modifications inside functions/methods do not affect the external value objects. Therefore, it's generally recommended to use pointers as arguments in functions/methods due to a couple of benefits:

Reduces memory usage, since passing by value requires duplication.

Allows the modification of specific data pointed to by the pointer inside the function.

Defer Function
The purpose of defer is to postpone the execution of a segment of code, and it's generally used for closing resources or executing necessary finalizing operations. The defer code block is executed no matter whether there is an error or not, which is similar to the function of the finally block in Java.
Defer uses a stack to manage the code that needs to be executed, hence the order of execution of deferred functions is opposite to the order of their declaration - following a "last in, first out" approach.

Pitfalls:
The value of the parameters in a defer function is determined at the time of declaring defer. When declaring a defer function, there are two ways to reference external variables: as function parameters and as closure references.

As function parameters, the value is passed to defer at the time of declaration, and the value is cached. The cached value is used for computation when the defer is called.
As closure references, the current value is determined based on the entire context when the defer function is executed (this method is recommended).

Comparison with Java

Code Style & Coding Conventions
Compared with Java, Golang has more stringent coding constraints. If such rules are not followed, your code might not be able to compile. The specific constraints are as follows:

A defined variable must be used or it can be replaced with _ to denote it can be ignored.
Imported packages must be used.
Braces must start at the end of the current line, and cannot be placed on a new line.

Access Control
Compared to Java, Golang's access control is straightforward - it only requires distinguishing between uppercase and lowercase initials.

Instance/Object Declaration and Creation
In Java, almost all object instances are created using the new keyword. On the other hand, in Golang, it's simpler - you just need to use a := T{} or a := &T{}

Difference between Structs and Classes
In Java, classes are foundational, and all logic relies on classes for existence.
However, in Golang, there is no concept of a class. The closest definition is a struct. Still, Golang's struct basically serves as a data carrier. In Golang, functions are the basis and can exist independent of structs. Also, in Java, invocations are driven based on classes or objects, whereas in Golang, function/method calls are partitioned by packages.

Functions and Methods
In Java, the term 'function' might be rarely used because all methods rely on the existence of class objects (this gap was filled after Java 8 with functional interfaces). In Golang, however, functions are first-class citizens, and methods are just special functions which include the current receiver as an implicit first parameter.

Pointers
For Java developers, pointers may appear slightly unfamiliar. You can consider it equivalent to object references in Java. Both Java and Golang pass values when making method calls. In Java, if a reference type (object, array, etc.) is passed, its pointer will be copied and passed. In Golang, you must explicitly pass the pointer of the struct; otherwise, you are just passing a copy of the object.

AOP/IOC/Transactional Declaration
One of the aspects making Golang challenging for Java developers is the lack of AOP (Aspect-Oriented Programming) capabilities. For example, to start a DB transaction in Golang, you need to manually write tx begin, tx end, tx rollback, and obtain the tx instance pointer. You also need to ensure that tx is not written incorrectly within a transaction, otherwise deadlocks and inconsistent queries might occur.
In contrast, in Java - thanks to AOP capabilities and the Spring framework - developers generally just need to focus on specific business logic and decide where to add a @Transactional annotation on a particular repo method. The subsequent transaction operations are managed by the framework.

I remember when I first started writing requirements, I encountered an embarrassing situation due to my lack of understanding. I couldn't query the data right after inserting it in the same transaction, which stalled my unit test for quite some time. Eventually, I found out that the SQL query didn't use the same tx connection.

IOC/DI (Inversion of Control/Dependency Injection) essentially implies the handing over of object creation and dependency injection to Spring during application startup in Java. Although Golang has the Wire injection framework, developers essentially need to predefine the instantiation rules, which could be viewed as a compile-time capability.

Sponsored by MarsCode
Welcome to join our Discord to discuss your ideas with us.

MarsCode Follow

MarsCode provides an AI-powered IDE and an AI extension to assist your programming tasks.

User Story EP3: How to Practice LeetCode Problems

Dawn Zhao — Fri, 14 Jun 2024 05:12:21 +0000

LeetCode is an online platform for coding interview preparation. The service provides coding and algorithmic problems intended for users to practice coding. LeetCode has gained popularity among job seekers and coding enthusiasts as a resource for technical interviews and coding competitions.

In the past, when using LeetCode, I preferred to write down my problem-solving thoughts using a txt editor or plain paper, and then code using VS Code. When I encountered problems that I couldn't understand, I needed to consult Google or ChatGPT. Although this method helped to clarify my thoughts, solving a single problem required frequent switching between multiple tools. This not only consumed a lot of time but also interrupted the continuity of my thinking, resulting in low overall efficiency. Therefore, I have been looking for a solution that could simplify this process and improve my practice efficiency.

Recently, a friend recommended an AI-powered Cloud IDE product called MarsCode to me. The overall experience is quite similar to VS Code, while also providing a ready-to-use development environment that supports debugging and running. The best part is that the built-in AI assistant can provide more accurate answers by fully understanding the context. Next, I will share my experience of using MarsCode.

Preparation

You need an account for MarsCode, which is very easy to get. Visit the MarsCode official website at MarsCode, and then register (or log in) to your account.

MarsCode offers various development templates, allowing users to start coding without worrying about setting up the programming environment. For instance, I chose Node.js here.

After creating, you can code just like you do with a local IDE.⬆️

You can run the index.js by clicking the 'Run' button or executing node index.js in the terminal.⬆️

Experience with MarsCode

Usually, when I encounter a problem, I first jot down my thoughts on scratch paper. This time, to test MarsCode's capabilities, I jumped directly into the coding phase. Let's take a look at a classic LeetCode problem: the "Longest Palindromic Substring"!

For LeetCode problems, we can write code with the assistance of MarsCode, or we can directly copy the LeetCode answer into the IDE and use AI capabilities to help us understand the problem and solution. MarsCode's AI assistant is very powerful, supporting features like code generation and code explanation. MarsCode can help me learn LeetCode in several key ways.

Coding

When writing code, MarsCode provides three ways to assist with coding:

While coding in the editor, the AI assistant infers your intentions based on the project context and comments, auto completing your code.
Generate code directly in the editor through the Inline AI Chat.
Chat with the AI assistant in the Side chat bar to get the AI to directly output the code.

For example, in the Node.js project created in the previous section, we can invoke Inline AI Chat in index.js.

When we input the problem, the AI assistant will infer the implementation of the function, even including the function call code!⬆️

After accepting the code, click the Run button to test the code and see the results.⬆️

If there are parts we don't understand, we can ask the AI assistant to explain them.⬆️

Writing test cases

Even though MarsCode has excellent coding capabilities, whether the code is completed by AI or by ourselves, we can use test cases to verify the correctness of the code.

In fact, with the help of AI, our test cases can be more comprehensive. Taking the "Longest Palindromic Substring" as an example, we can use the AI assistant to generate test cases using Mocha.

This way, we can easily and quickly verify accuracy through the test cases.⬆️

Debug

MarsCode provides templates that already support debugging capabilities. If there are any doubts about the code execution process, we can also use the Debug feature to understand the code execution step by step.

Open the Debug panel on the right side and click the "Start Debugging" button.⬆️

Exploring Better Solutions with AI

We can explore more solutions by conversing with MarsCode's AI assistant. For example, in the previous example, we used the center expansion algorithm for the longest palindromic substring, but another common solution is dynamic programming.

If we are not familiar with dynamic programming, we can ask further: What is dynamic programming?⬆️

We can also ask the AI assistant to provide some examples of dynamic programming. ⬆️

As you can see, on MarsCode, the AI assistant acts like a teammate, helping us gradually increase our understanding of the problem through conversation.

Conclusion

Overall, my experience with MarsCode has been excellent. Features like hassle-free setup, free AI, and resource environments are very helpful for validating ideas and boosting efficiency. However, when practicing LeetCode, your own thought process is paramount. I recommend first organizing your ideas and then using MarsCode to solve the problems. This approach maintains the flow of thought while leveraging the powerful tools MarsCode offers, ensuring you effectively and solidly grasp algorithms and coding techniques.

Wishing you great success in your LeetCode practice!🎉